Firefox 3: graphic problem, scroll
us...@domain.invalid
Scrolling on this page:
http://kimludvigsen.dk/programmer-internet-firefox.html
is very slow. Both when using the scroll wheel and when
using the scroll bar.
The page scrolls nicely in Windows, though a little less
smooth than other pages. I think the problem is the use of
z-index (the menu), but there shouldn't be this big
difference in Windows and OS/2.
There is no problem scrolling the page in Firefox 2, where
it actually scrolls more smoothly than Firefox 3 in Windows.
Regards
Kim Ludvigsen
Dave Yeo
Dave
Rich Walsh
I eliminated all of the z-index stuff on that page and the
scrolling was still really bad. Removing the "position: fixed;"
CSS attribute for your 'fastmenu' restored normal scrolling
speed. Try replacing the menu with something simpler like a
graphic or a line of text. If the problem persists, it's
definitely Bugzilla material.
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
Peter Weilbacher
It's somewhat slow and very CPU intensive on Linux, too. That's why it
first reminded me of https://bugzilla.mozilla.org/show_bug.cgi?id=405740
but it may well be something different. There's also
<https://bugzilla.mozilla.org/show_bug.cgi?id=424308>.
If we only had a working profiler for OS/2...
--
Please Enhanced OS/2 builds of Mozilla applications
reply in http://pmw-warpzilla.sf.net/
newsgroup
Steve's Warpzilla Tips: http://www.os2bbs.com/os2news/Warpzilla.html
Peter Weilbacher
> It's somewhat slow and very CPU intensive on Linux, too. That's why it
> first reminded me of https://bugzilla.mozilla.org/show_bug.cgi?id=405740
> but it may well be something different. There's also
> <https://bugzilla.mozilla.org/show_bug.cgi?id=424308>.
And <https://bugzilla.mozilla.org/show_bug.cgi?id=361754> and
<https://bugzilla.mozilla.org/show_bug.cgi?id=372039>. Really not sure
what of these could be the bug in this case, if any.
Kim Ludvigsen
> On Wed, 18 Jun 2008 19:58:42 UTC, us...@domain.invalid wrote:
>
>> Scrolling on this page:
>> http://kimludvigsen.dk/programmer-internet-firefox.html
>> is very slow. Both when using the scroll wheel and when
>> using the scroll bar.
>
> scrolling was still really bad. Removing the "position: fixed;"
You're right, removing position:fixed restores normal
scrolling speed. But that is not a solution. position:fixed
should work in OS/2 as well as in Windows and Linux.
But it is not only position:fixed, that is the cause. This site:
http://www.w3.org/Style/Examples/007/menus
scrolls almost normally. It is a little bit slower than
other pages, but much faster than mine.
Kind regards
Kim Ludvigsen
Kim Ludvigsen
> On 19.06.2008 09:48, Peter Weilbacher wrote:
>
>> It's somewhat slow and very CPU intensive on Linux, too. That's why it
>> first reminded me of https://bugzilla.mozilla.org/show_bug.cgi?id=405740
>> but it may well be something different. There's also
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=424308>.
>
> And <https://bugzilla.mozilla.org/show_bug.cgi?id=361754> and
> <https://bugzilla.mozilla.org/show_bug.cgi?id=372039>. Really not sure
> what of these could be the bug in this case, if any.
It doesn't seem to be any of those bugs. The test pages
scrolls with normal speed.
Rich have nailed it down to have something to do with
position:fixed. I can't imagine that the css rendering
should be different on the various platforms, so I rather
suspect the graphic engine is to blame.
Kind regards
Kim Ludvigsen
Rich Walsh
That's why I suggested replacing the menu with something simpler:
to see if the underlying cause was the table you're using, its
background image, or whatever.
Kim Ludvigsen
> On Thu, 19 Jun 2008 08:45:00 UTC, Kim Ludvigsen <us...@domain.invalid> wrote:
>
>> But that is not a solution. position:fixed
>> should work in OS/2 as well as in Windows and Linux.
>>
>
> That's why I suggested replacing the menu with something simpler:
> to see if the underlying cause was the table you're using, its
> background image, or whatever.
Oh, I misunderstood you. I though you meant as a solution. I
can now see, you meant as a test. I will try to play around
with the codes.
Kind regards
Kim Ludvigsen
Heiko Nitzsche
I don't know if this works with OS/2 GCC port but
it might be worth a try.
GCC has a built-in profiler that can be enabled with
-fprofile-arcs. It instruments the code to collect
execution time per line (according to the docs). At
program shutdown the logfile is written. The program must
end normally (no kill). Otherwise the log is not written.
There is also an option to instrument the code to record
executed code lines for coverage analysis. This is what
we use at work on Linux. It works reasonably well. So far
I did not use the profiling mechanism, so I have no clue
how it works and how accurate it is.
You can restrict the instrumention to specific source files
to reduce the logging output. At least on Linux for C++ code
(compiled with g++) the dynamic libc is missing a function
required by the profiler (at runtime you get an unresolved
symbol). Thus you need to statically link all libraries with
libc to make the mechanims work.
Here is a link to the options in the GCC 3.3.6 online doc:
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Debugging-Options.html#Debugging-Options
Peter Weilbacher
> > If we only had a working profiler for OS/2...
>
> I don't know if this works with OS/2 GCC port but
> it might be worth a try.
>
> GCC has a built-in profiler that can be enabled with
> -fprofile-arcs. It instruments the code to collect
> execution time per line (according to the docs). At
> program shutdown the logfile is written. The program must
> end normally (no kill). Otherwise the log is not written.
Would have been nice, but I get
R:\tmp\cciHChOb.o(simple.c) : error LNK2029: "___bb_init_func" : unresolved external
when even linking a simple ("Hello World" type) program with that
option.
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Heiko Nitzsche
>
> R:\tmp\cciHChOb.o(simple.c) : error LNK2029: "___bb_init_func" : unresolved external
>
> when even linking a simple ("Hello World" type) program with that
> option.
Yes, this is the function I couldn't remember the name.
Did you link the runtime statically? In the runtime dll this
function is missing, at least on Linux static linking helps.
Heiko Nitzsche
I tried with a simple hello world app. Compiled and linked with:
g++ -g -fprofile-arcs -ftest-coverage -static-libgcc -o x.exe x.cpp
Works fine. When x.exe has finished I get a x.da, x.bb and x.bbg.
Unfortunately this is only for coverage analysis. You need to run
gcov x.cpp
afterwards and gcov will write a commented ASCII file x.cpp.gcov.
In my example it looks as follows (don't think about usefulness
of the code :) ):
-: 0:Source:x.cpp
-: 0:Object:x.bb
-: 1:
-: 2:#include <stdlib.h>
-: 3:#include <stdio.h>
-: 4:
-: 5:int main(void)
1: 6:{
1: 7: int i;
1: 8: int x = 5000;
1: 9: double f = 0.0;
-: 10:
5001: 11: for (i = 0; i < x; i++)
-: 12: {
5000: 13: f += 1.1 * i;
-: 14: }
-: 15:
1: 16: printf("f = %lf\n", f);
-: 17:
1: 18: return 0;
1: 19:}
The information might already be useful to figure out when which code
is executed and how often.
To be able to use gprof the files must be compiled and linked with -pg
option (writes gprof meta info):
g++ -pg -g -fprofile-arcs -ftest-coverage -static-libgcc -o x.exe x.cpp
If you only want to use gprof, you can skip -fprofile-arcs and -ftest-coverage.
At program x.exe has finished a gmon.out should have been written.
Unfortunately I always get an error from ld.exe complaining about
a missing object file:
E:/GCC.335/usr/i386-pc-os2-emx/bin/ld.exe: No such file or directory for gcrt0.o
That is going beyond my knowledge of gcc environment on OS/2.
Maybe I forget to prepare some libs after the installation.
Heiko Nitzsche
Peter Weilbacher
> I tried with a simple hello world app. Compiled and linked with:
>
> g++ -g -fprofile-arcs -ftest-coverage -static-libgcc -o x.exe x.cpp
>
> Works fine. When x.exe has finished I get a x.da, x.bb and x.bbg.
> Unfortunately this is only for coverage analysis. You need to run
>
> gcov x.cpp
>
> afterwards and gcov will write a commented ASCII file x.cpp.gcov.
> In my example it looks as follows (don't think about usefulness
> of the code :) ):
> The information might already be useful to figure out when which code
> is executed and how often.
Thanks, yes, this should get us a long way already, I'm trying to create
a Firefox 3 build with that included.
> To be able to use gprof the files must be compiled and linked with -pg
> option (writes gprof meta info):
>
> g++ -pg -g -fprofile-arcs -ftest-coverage -static-libgcc -o x.exe x.cpp
>
> If you only want to use gprof, you can skip -fprofile-arcs and
> -ftest-coverage.
>
> At program x.exe has finished a gmon.out should have been written.
> Unfortunately I always get an error from ld.exe complaining about
> a missing object file:
>
> E:/GCC.335/usr/i386-pc-os2-emx/bin/ld.exe: No such file or directory for gcrt0.o
>
> That is going beyond my knowledge of gcc environment on OS/2.
> Maybe I forget to prepare some libs after the installation.
I don't think gprof works with OMF format. I have tried that before.
Peter Weilbacher
> Thanks, yes, this should get us a long way already, I'm trying to create
> a Firefox 3 build with that included.
It did complete, and created all those .bb and .bbg files. But I forgot
to modify the makefile system to copy them to the output directory. And
it seems that the runtime .da files are created in the directory that
the binaries were linked in. That will make any analysis hard. Let's see.
I haven't really understood, how gcov finds the .bb* and .da files
corresponding to the source file that one gives on the command line.
--
Please Enhanced OS/2 builds of Mozilla applications
reply in http://pmw-warpzilla.sf.net/
newsgroup
Heiko Nitzsche
> to modify the makefile system to copy them to the output directory. And
> it seems that the runtime .da files are created in the directory that
> the binaries were linked in. That will make any analysis hard. Let's see.
> I haven't really understood, how gcov finds the .bb* and .da files
> corresponding to the source file that one gives on the command line.
The location of the source file is coded in the .bb file.
When compiling the .bb and .bbg files are created in the directory
the compiler is run. The source filename is stored in .bb. You must
call gcov always from the directory the .bb file is located. It will
create the commented source file always beside the .bb file.
The .da file is always created where the compiler wrote the .bb/.bbg
files, independent from where the binary is run.
Example 1: Compile from within the source directory
----------
dir\x.cpp
dir\bin
cd dir
g++ -g -fprofile-arcs -ftest-coverage -static-libgcc -o bin\x.exe x.cpp
bin\x.exe
gcov x.cpp
-> x.bb and .bbg are created beside x.cpp at compile time.
When you run x.exe the x.da file is created beside x.cpp.
-> gcov x.cpp in dir creates x.cpp.gcov
That's the best way to do it because it prevents potential name clashes.
Example 2: Compile from within the bin directory
----------
dir\x.cpp
dir\bin
cd dir\bin
g++ -g -fprofile-arcs -ftest-coverage -static-libgcc -o x.exe ..\x.cpp
x.exe
gcov x.cpp
-> x.bb and .bbg are created beside x.exe at compile time.
When you run x.exe the x.da file is created beside x.bb and x.bbg,
which is beside x.exe.
-> gcov x.cpp in dir\bin creates x.cpp.gcov beside x.exe
This scenario may cause filename clashes if there are several files
with the same name from different source dirs.
Better go with example 1 which I think is anyway the most used way.
One additional note:
--------------------
When you run the binary multiple times, the profiling data is added
to the existing data and not replaced. If you want a clean startup
every time, simply delete the .da before.
Heiko Nitzsche
If you want to profile some specific source files, it is sufficient
to compile only them with the -f options. Of course, you still
need to link libgcc statically.
Peter Weilbacher
>> It did complete, and created all those .bb and .bbg files. But I forgot
>> to modify the makefile system to copy them to the output directory. And
>> it seems that the runtime .da files are created in the directory that
>> the binaries were linked in. That will make any analysis hard. Let's see.
>> I haven't really understood, how gcov finds the .bb* and .da files
>> corresponding to the source file that one gives on the command line.
>
> The location of the source file is coded in the .bb file.
>
> When compiling the .bb and .bbg files are created in the directory
> the compiler is run. The source filename is stored in .bb. You must
> call gcov always from the directory the .bb file is located. It will
> create the commented source file always beside the .bb file.
> The .da file is always created where the compiler wrote the .bb/.bbg
> files, independent from where the binary is run.
I played with this a bit today, I can run gcov from any directory, as
long as I give the relative directory to the .bb file, with _backward_
slashes. E.g.
gcov ..\..\widget\src\os2\nsWindow.bb
works when run after the compilation from the dist\bin directory.
So to look at bug 258136 I created the following shell script (would
probably be easier with REXX, which I don't speak at all):
FAST_URL=<path_to_fast_page>
SLOW_URL=<path_to_slow_page>
DIR_FAST_PAGE=fast
DIR_SLOW_PAGE=slow
find ../../ -name "*.da" -exec rm -f {} \;
firefox ${FAST_URL} > fast.log 2>&1
for bb in `find ../../ -name "*.bb"`
do
echo $bb
CMD=`echo $bb | sed -e 's,/,\\\,g' -e 's,^,gcov ,'`
echo $CMD
cmd /c $CMD
done
find . -maxdepth 1 -name "*.gcov" -exec mv -f {} ${DIR_FAST_PAGE} \;
grep -v '-\:' long_lowres\*.gcov | grep -v '#####\:' | sort -k2n > ${DIR_FAST_PAGE}/all_sort
find ../../ -name "*.da" -exec rm -f {} \;
firefox ${SLOW_URL} > slow.log 2>&1
for bb in `find ../../ -name "*.bb"`
do
echo $bb
CMD=`echo $bb | sed -e 's,/,\\\,g' -e 's,^,gcov ,'`
echo $CMD
cmd /c $CMD
done
find . -maxdepth 1 -name "*.gcov" -exec mv -f {} ${DIR_SLOW_PAGE} \;
grep -v '-\:' long_lowres\*.gcov | grep -v '#####\:' | sort -k2n > ${DIR_SLOW_PAGE}/all_sort
It takes quite a while to run this but then I can compare what was
called most often throughout the codebase by looking at *\all_sort.
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/