Custom Query (301 matches)
Results (19 - 21 of 301)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#182 | invalid | Arora page loading performance | ||
Description |
With I compare my current 4.6.3 build with an older 4.6.2 I notice a performance degration in Arora. Basically, when the page load progress reaches about 60%, the CPU load maxes out and stays there for a while. After that, the page is shown correctly. With 4.6.2 this CPU load peak is there as well, but smaller and shorter. It seems to be especially visible when a page is loaded for the first time after Arora has been started. Also it might depend on the page. I saw it with http://www.commtalk.org/ and http://www.s-t.de/ . Could someone of you try to compare Arora's loading performance running on top of 4.6.3 and 4.6.2 ? Especially the sequence: start the program - goto one of the mentioned URLs. |
|||
#166 | fixed | Arora web browser cannot locate to existing instance | ||
Description |
The Arora web browser is using local IPC to detect if it is already running and to pass command line arguments along. This will fail on OS/2. The reason for that is that OS/2's TCP/IP does not fully support the PF_UNIX protocol family. Thus the implementation of QLocalServer and QLocalSocket does not work.
The suggested fix is basically a combination of the mechanism used under Windows (pipes) with the name syntax required by OS/2's TCP/IP ( |
|||
#168 | fixed | Arora web browser crashes in LIBC | ||
Description |
When surfing around Arora often crashes with the following register dump: Killed by SIGSEGV pid=0x9128 ppid=0x0017 tid=0x0001 slot=0x007e pri=0x0200 mc=0x0001 C:\PROG\ARORA\ARORA.EXE LIBC063 0:00053f6a cs:eip=005b:1dc63f6a ss:esp=0053:0214e388 ebp=0214e3c8 ds=0053 es=0053 fs=150b gs=0000 efl=00212216 eax=00000000 ebx=20392fd4 ecx=00010000 edx=00000000 edi=00000000 esi=25300000 Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. It's an attempt to "setmem" a NULL pointer. I tried to analyze the problem and to me it appears that this comes from /webkit/JavaScriptCore/runtime/Collector.cpp, line 273. Digging a bit into the implementation of posix_memalign() in KLIBC, I tend to think that this function will not work correctly, when the requested alignment is larger than a page size. But exactly this happens in line 272. I suggest to modify JavaScriptCore?\wtf\platform.h so that for OS/2 HAVE_POSIX_MEMALIGN is zero. Note that there are two instances of the JavaScriptCore? in the 3rdparty subtree: one that goes into QtScript? and one that ends up in QtWebKit?. At the moment I'm writing this, my finding is just a hypothesis. I will try to prove it, when my other builds are complete... |