Hi, I stumbled across this post on fltk.bugs: http://fltk.org/newsgroups.php?s5281+gfltk.bugs+v5290+T0 This is great for us, as it allows us to implement efficient double buffering without X11 specific hacks. Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test. Cheers, Johannes
Hi, my first patch broke test programs in dw2/test/ (as they don't use clear_double_buffer() as dillo-fltk does). Corrected patch attached. Sorry for that, Johannes On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Hi,
I stumbled across this post on fltk.bugs: http://fltk.org/newsgroups.php?s5281+gfltk.bugs+v5290+T0
This is great for us, as it allows us to implement efficient double buffering without X11 specific hacks. Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
Cheers, Johannes
diff -r 0949076de1d4 configure.in --- a/configure.in Sat Apr 05 13:33:25 2008 +0200 +++ b/configure.in Sat Apr 05 16:48:27 2008 +0200 @@ -21,6 +21,7 @@ AC_ARG_ENABLE(ansi, [ --enable-ansi AC_ARG_ENABLE(ansi, [ --enable-ansi Try to compile and run with ANSI flags], , enable_ansi=no) AC_ARG_ENABLE(rtfl, [ --enable-rtfl Build with rtfl messages], enable_rtfl=yes) +AC_ARG_ENABLE(doublebuffer, [ --disable-doublebuffer Disable double buffering for drawing], disable_doublebuffer=yes)
AC_PROG_CXX AM_PROG_CC_STDC @@ -61,6 +62,9 @@ if test "x$enable_rtfl" = "xyes" ; then if test "x$enable_rtfl" = "xyes" ; then CXXFLAGS="$CXXFLAGS -DDBG_RTFL" fi +if test "x$disable_doublebuffer" = "xyes" ; then + CXXFLAGS="$CXXFLAGS -DNO_DOUBLEBUFFER" +fi
dnl ----------------------- dnl Checks for header files diff -r 0949076de1d4 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Apr 05 13:33:25 2008 +0200 +++ b/dw/fltkviewbase.cc Sat Apr 05 16:48:27 2008 +0200 @@ -38,6 +38,8 @@ namespace dw { namespace dw { namespace fltk {
+::fltk::Image *FltkViewBase::backBuffer; + FltkViewBase::FltkViewBase (int x, int y, int w, int h, const char *label): Group (x, y, w, h, label) { @@ -46,13 +48,17 @@ FltkViewBase::FltkViewBase (int x, int y bgColor = WHITE; lastDraw = time(0); drawDelay = 2; /* in seconds */ +#ifndef NO_DOUBLEBUFFER + if (!backBuffer) { + backBuffer = new Image (); + } +#endif }
FltkViewBase::~FltkViewBase () { cancelQueueDraw (); } -
void FltkViewBase::draw () { @@ -78,9 +84,27 @@ void FltkViewBase::draw ()
if (!viewRect.empty ()) { push_clip (viewRect); +#ifndef NO_DOUBLEBUFFER + { + GSave gsave; + + backBuffer->setsize (viewRect.w (), viewRect.h ()); + backBuffer->make_current (); + translate (-viewRect.x () , -viewRect.y ()); + + setcolor (bgColor); + fillrect (viewRect); + theLayout->expose (this, rect); + } + + make_current (); + backBuffer->draw (Rectangle (0, 0, viewRect.w (), viewRect.h ()), + viewRect); +#else setcolor (bgColor); fillrect (viewRect); theLayout->expose (this, rect); +#endif pop_clip (); } } diff -r 0949076de1d4 dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh Sat Apr 05 13:33:25 2008 +0200 +++ b/dw/fltkviewbase.hh Sat Apr 05 16:48:27 2008 +0200 @@ -2,6 +2,7 @@ #define __DW_FLTKVIEWBASE_HH__
#include <fltk/Group.h> +#include <fltk/Image.h> #include <fltk/Scrollbar.h>
#include "fltkcore.hh" @@ -15,6 +16,7 @@ private: private: int bgColor; core::Region drawRegion; + static ::fltk::Image *backBuffer;
void drawChildWidgets ();
Hi, On Sat, Apr 05, 2008 at 10:42:43PM +0200, Johannes Hofmann wrote:
Hi,
my first patch broke test programs in dw2/test/ (as they don't use clear_double_buffer() as dillo-fltk does). Corrected patch attached.
Committed! Great flicker reduction was noticed in my fast computer. I'm yet to test in the slow one. It has been a long struggle against flickering and I can only feel happy, and grateful, that this is finally ironed out.
[corvid wrote:] With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds). If I comment out clear_double_buffer(), it takes no perceived time.
Some days ago (and before) I've tested dillo2 without Johannes' patch, in a Thinkpad 380Z, and also with a 385XD. Both render antialiased fonts much faster than you describe.
[Johannes wrote:] There is two things I don't understand. First, antialiased fonts seem to be extremely slow on your system. What about the test programs from fltk, are they usable? Or other programs that use antialiased fonts?
Second, commenting out clear_double_buffer() seems to make it faster - not just reducing flicker.
Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards). Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on. Disclaimer: I may be completely wrong on my guess. Finally with regard to making partial double buffering a run time option, I'd prefer to leave it "as is" for now, because it looks like an improvement in all cases so far. -- Cheers Jorge.-
Jorge wrote:
[corvid wrote:] With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds).
(Just wanted to mention that the redraw became rare when I tried running with it some more, and went away when I paid enough attention to try to figure out what conditions triggered it...)
If I comment out clear_double_buffer(), it takes no perceived time.
Some days ago (and before) I've tested dillo2 without Johannes' patch, in a Thinkpad 380Z, and also with a 385XD. Both render antialiased fonts much faster than you describe.
[Johannes wrote:] There is two things I don't understand. First, antialiased fonts seem to be extremely slow on your system. What about the test programs from fltk, are they usable? Or other programs that use antialiased fonts?
Second, commenting out clear_double_buffer() seems to make it faster - not just reducing flicker.
Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards).
Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on.
Sounds like I'll have to play around with my configuration. I expected it to be slow, so nothing ever drew my suspicion...
On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote:
Hi,
On Sat, Apr 05, 2008 at 10:42:43PM +0200, Johannes Hofmann wrote:
Hi,
my first patch broke test programs in dw2/test/ (as they don't use clear_double_buffer() as dillo-fltk does). Corrected patch attached.
Committed!
Great flicker reduction was noticed in my fast computer. I'm yet to test in the slow one.
It has been a long struggle against flickering and I can only feel happy, and grateful, that this is finally ironed out.
[corvid wrote:] With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds). If I comment out clear_double_buffer(), it takes no perceived time.
Some days ago (and before) I've tested dillo2 without Johannes' patch, in a Thinkpad 380Z, and also with a 385XD. Both render antialiased fonts much faster than you describe.
[Johannes wrote:] There is two things I don't understand. First, antialiased fonts seem to be extremely slow on your system. What about the test programs from fltk, are they usable? Or other programs that use antialiased fonts?
Second, commenting out clear_double_buffer() seems to make it faster - not just reducing flicker.
Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards).
Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on.
That's what I think now as well. 4s per page is very slow. I almost finished to reinstall my old Extensa 367T which has a 200Mhz Pentium and a Neomagic graphics card. It should be pretty comparable to the thinkpad 380XD. Cheers, Johannes
Johannes wrote:
On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote:
Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards).
Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on.
That's what I think now as well. 4s per page is very slow. I almost finished to reinstall my old Extensa 367T which has a 200Mhz Pentium and a Neomagic graphics card. It should be pretty comparable to the thinkpad 380XD.
I see that if I switch from 16-bit to 8-bit, drawing a page goes from 4 seconds to maybe half a second. (I'm not using 24-bit because neomagic(4) says "All depths are accelerated except for depth 24 which is only accelerated on NM2200 and newer models." This has NM2160.)
corvid wrote:
Johannes wrote:
On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote:
Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards).
Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on.
That's what I think now as well. 4s per page is very slow. I almost finished to reinstall my old Extensa 367T which has a 200Mhz Pentium and a Neomagic graphics card. It should be pretty comparable to the thinkpad 380XD.
I see that if I switch from 16-bit to 8-bit, drawing a page goes from 4 seconds to maybe half a second.
(I'm not using 24-bit because neomagic(4) says "All depths are accelerated except for depth 24 which is only accelerated on NM2200 and newer models." This has NM2160.)
*tries 24-bit anyway* Half a second to redraw. Nice. And I think video is speedier. On the other hand, scrolling in an rxvt is now slow, and I think dragging one around the screen is more sluggish than usual.
On Thu, Apr 10, 2008 at 04:36:35PM +0000, corvid wrote:
Johannes wrote:
On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote:
Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards).
Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on.
That's what I think now as well. 4s per page is very slow. I almost finished to reinstall my old Extensa 367T which has a 200Mhz Pentium and a Neomagic graphics card. It should be pretty comparable to the thinkpad 380XD.
I see that if I switch from 16-bit to 8-bit, drawing a page goes from 4 seconds to maybe half a second.
(I'm not using 24-bit because neomagic(4) says "All depths are accelerated except for depth 24 which is only accelerated on NM2200 and newer models." This has NM2160.)
I'm seeing this now on my old laptop with the Neomagic card. Antialiased fonts are horribly slow. They get pretty fast however if I comment out disable_double_buffer(). I think this is a driver problem, but I will need to do some more tests. Are there any other users with old hardware (slow CPU, but perhaps other graphics card)? Johannes
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run? Regards, Jeremy Henty
Hi Jeremy, On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote:
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run?
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course... BTW, do you think double buffering should be a compile time option - as in the patch? As no special includes are needed we might make it a run time option as well. Regards, Johannes
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
BTW, do you think double buffering should be a compile time option - as in the patch? As no special includes are needed we might make it a run time option as well.
I don't know enough about the issues to say. Why would someone want to disable double buffering? Resource constraints? An unusual X server that doesn't support it very well? Regards, Jeremy Henty
On Tue, Apr 08, 2008 at 05:11:58PM +0100, Jeremy Henty wrote:
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
Yes we should definately test in on some low-end machines. Remote X11 is also a good test.
BTW, do you think double buffering should be a compile time option - as in the patch? As no special includes are needed we might make it a run time option as well.
I don't know enough about the issues to say. Why would someone want to disable double buffering? Resource constraints? An unusual X server that doesn't support it very well?
I can only think of debugging. Without double buffering you see excessive redraws immediately. Regards, Johannes
Hi, On Tue, Apr 08, 2008 at 08:03:04PM +0200, Johannes Hofmann wrote:
On Tue, Apr 08, 2008 at 05:11:58PM +0100, Jeremy Henty wrote:
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
Yes we should definately test in on some low-end machines. Remote X11 is also a good test.
I can test it on a slow machine, but next week...
BTW, do you think double buffering should be a compile time option - as in the patch? As no special includes are needed we might make it a run time option as well.
I don't know enough about the issues to say. Why would someone want to disable double buffering? Resource constraints? An unusual X server that doesn't support it very well?
I can only think of debugging. Without double buffering you see excessive redraws immediately.
The problem we had before the patch in current FLTK, was of memory usage on restrained/embedded systems (one buffer per open window IIRC). Although I'm not sure yet, it'd be good to have it as a dillorc option to make faster comparisons. :-) -- Cheers Jorge.-
Jeremy wrote:
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what. Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote:
Jeremy wrote:
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html
Hm, I see something... And I can click on the "Individual", "Businesses"... images. Cheers, Johannes
Johannes wrote:
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote:
Jeremy wrote:
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer(). If that sounds wrong, I'll double-check that I applied it correctly. I had cut and pasted from the mail, and maybe I missed something.
Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html
Hm, I see something... And I can click on the "Individual", "Businesses"... images.
Is it slow when you scroll around through the items in the menu of forms at the bottom?
On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote:
Jeremy wrote:
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer().
Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()? The point of my patch is to make drawing flicker free as with clear_double_buffer() commented out, but without the memory overhead. What machine do you have? Perhaps I should try to revive an old laptop of mine...
If that sounds wrong, I'll double-check that I applied it correctly. I had cut and pasted from the mail, and maybe I missed something.
Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html
Hm, I see something... And I can click on the "Individual", "Businesses"... images.
Is it slow when you scroll around through the items in the menu of forms at the bottom?
It's certainly usable. However you might have noticed that drawing antialiased fonts consumes much more CPU than raster fonts. So you might try fltk2 configured with the --disable-xft option. I actually like good raster fonts better than antialiased ones, but that's a matter of taste. Cheers, Johannes
Johannes wrote:
On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote:
Jeremy wrote:
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer().
Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()?
With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds). If I comment out clear_double_buffer(), it takes no perceived time.
The point of my patch is to make drawing flicker free as with clear_double_buffer() commented out, but without the memory overhead.
What machine do you have? Perhaps I should try to revive an old laptop of mine...
a thinkpad 380XD. It had its tenth birthday in February. I've been really meaning to get something newer for... a year now. (If you think that's bad, I used a Commodore until 1993 -- if you're old enough for that to mean much to you, anyway).
Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html
Hm, I see something... And I can click on the "Individual", "Businesses"... images.
Is it slow when you scroll around through the items in the menu of forms at the bottom?
It's certainly usable. However you might have noticed that drawing antialiased fonts consumes much more CPU than raster fonts. So you might try fltk2 configured with the --disable-xft option. I actually like good raster fonts better than antialiased ones, but that's a matter of taste.
It currently must take like a minute to go from one item to the next. Probably more. I'll try --disable-xft.
Oh wow. Sure, I knew that antialiasing slows things down, but I'd never imagined the difference was so incredibly dramatic. It's now fine with clear_double_buffer(), and the menu I'd mentioned now goes at _full_ _speed_.
On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote:
Jeremy wrote:
There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer().
Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()?
With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds).
Ouch, 4 seconds is really slow... And there should be now additional redraw in this case.
If I comment out clear_double_buffer(), it takes no perceived time.
This is interesting. I will try to reproduce this on my old laptop. Can you please run xdpyinfo on your machine and check whether or not you have RENDER and XDBE extensions enabled in your X-server?
The point of my patch is to make drawing flicker free as with clear_double_buffer() commented out, but without the memory overhead.
What machine do you have? Perhaps I should try to revive an old laptop of mine...
a thinkpad 380XD. It had its tenth birthday in February. I've been really meaning to get something newer for... a year now. (If you think that's bad, I used a Commodore until 1993 -- if you're old enough for that to mean much to you, anyway).
Old enough - yes, but I had an Atari 800XL back then :-)
Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html
Hm, I see something... And I can click on the "Individual", "Businesses"... images.
Is it slow when you scroll around through the items in the menu of forms at the bottom?
It's certainly usable. However you might have noticed that drawing antialiased fonts consumes much more CPU than raster fonts. So you might try fltk2 configured with the --disable-xft option. I actually like good raster fonts better than antialiased ones, but that's a matter of taste.
It currently must take like a minute to go from one item to the next. Probably more. I'll try --disable-xft.
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Johannes wrote:
On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote:
Jeremy wrote: > There are no regressions that I can see. It feels just as fast and > somewhat less flickery. Mind you, this is a fairly fast machine, it > would be useful if someone with a more low-end box tried it out.
I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer().
Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()?
With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds).
Ouch, 4 seconds is really slow... And there should be now additional redraw in this case.
If I comment out clear_double_buffer(), it takes no perceived time.
This is interesting. I will try to reproduce this on my old laptop.
Can you please run xdpyinfo on your machine and check whether or not you have RENDER and XDBE extensions enabled in your X-server?
It shows RENDER. No XDBE, but there is DOUBLE-BUFFER, which Xorg.0.log says comes from "dbe". Is it misconfigured? I wouldn't be too surprised...
(If you think that's bad, I used a Commodore until 1993 -- if you're old enough for that to mean much to you, anyway).
Old enough - yes, but I had an Atari 800XL back then :-)
Yeah, I remembered after I sent it that the 8-bit world survived a long time in Germany, and so that was bound to sound relatively sane. And dillo in 2008 draws a certain sort of person anyway.
On Wed, Apr 09, 2008 at 04:11:51PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > Jeremy wrote: > > There are no regressions that I can see. It feels just as fast and > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > would be useful if someone with a more low-end box tried it out. > > I wonder who you could be talking about :) > I applied it, but running without double buffering is just not an > option for me. Drawing is just very slow no matter what.
Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer().
Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()?
With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds).
Ouch, 4 seconds is really slow... And there should be now additional redraw in this case.
If I comment out clear_double_buffer(), it takes no perceived time.
This is interesting. I will try to reproduce this on my old laptop.
Can you please run xdpyinfo on your machine and check whether or not you have RENDER and XDBE extensions enabled in your X-server?
It shows RENDER. No XDBE, but there is DOUBLE-BUFFER, which Xorg.0.log says comes from "dbe". Is it misconfigured? I wouldn't be too surprised...
No, DOUBLE-BUFFER is correct. There is two things I don't understand. First, antialiased fonts seem to be extremely slow on your system. What about the test programs from fltk, are they usable? Or other programs that use antialiased fonts? Second, commenting out clear_double_buffer() seems to make it faster - not just reducing flicker. Johannes
Johannes wrote:
On Wed, Apr 09, 2008 at 04:11:51PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote:
Johannes wrote:
On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote:
Johannes wrote: > On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > > Jeremy wrote: > > > There are no regressions that I can see. It feels just as fast and > > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > > would be useful if someone with a more low-end box tried it out. > > > > I wonder who you could be talking about :) > > I applied it, but running without double buffering is just not an > > option for me. Drawing is just very slow no matter what. > > Is dillo-fltk useable for you with the patch, but with > clear_double_buffer() as in current cvs? > If not, what exactly is the problem?
Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer().
Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()?
With clear_double_buffer(), I hit page down on an already-loaded page. It takes four seconds to draw the screen of text (well, and then it performs a redraw for another three or four seconds).
Ouch, 4 seconds is really slow... And there should be now additional redraw in this case.
If I comment out clear_double_buffer(), it takes no perceived time.
This is interesting. I will try to reproduce this on my old laptop.
Can you please run xdpyinfo on your machine and check whether or not you have RENDER and XDBE extensions enabled in your X-server?
It shows RENDER. No XDBE, but there is DOUBLE-BUFFER, which Xorg.0.log says comes from "dbe". Is it misconfigured? I wouldn't be too surprised...
No, DOUBLE-BUFFER is correct.
There is two things I don't understand. First, antialiased fonts seem to be extremely slow on your system. What about the test programs from fltk, are they usable? Or other programs that use antialiased fonts?
Things are all right as long as I don't insert a clear_double_buffer().
Second, commenting out clear_double_buffer() seems to make it faster - not just reducing flicker.
I wonder whether there's a way to set double-buffering for menus.
Hi Johannes, On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Hi Jeremy,
On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote:
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run?
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
I found something that looks like a bug in double buffering (it doesn't happen with the previous code). If you: - ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page. You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL. Please give it a look. -- Cheers Jorge.-
Hi Jorge, On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote:
Hi Johannes,
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Hi Jeremy,
On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote:
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run?
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
I found something that looks like a bug in double buffering (it doesn't happen with the previous code).
If you:
- ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page.
You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL.
Please give it a look.
Patch 1 should fix the problem. The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part. Cheers, Johannes
On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote:
Hi Jorge,
On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote:
Hi Johannes,
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Hi Jeremy,
On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote:
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run?
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
I found something that looks like a bug in double buffering (it doesn't happen with the previous code).
If you:
- ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page.
You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL.
Please give it a look.
Patch 1 should fix the problem.
Good! Committed.
The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part.
I'd commit bracketed as: #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif [Drawing code here...] #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif Would it be OK? -- Cheers Jorge.-
On Thu, Apr 17, 2008 at 08:53:23AM -0400, Jorge Arellano Cid wrote:
On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote:
Hi Jorge,
On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote:
Hi Johannes,
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Hi Jeremy,
On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote:
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run?
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
I found something that looks like a bug in double buffering (it doesn't happen with the previous code).
If you:
- ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page.
You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL.
Please give it a look.
Patch 1 should fix the problem.
Good!
Committed.
The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part.
I'd commit bracketed as:
#ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif
[Drawing code here...]
#ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif
Would it be OK?
Yes, of course. Cheers, Johannes
On Thu, Apr 17, 2008 at 05:28:34PM +0200, Johannes Hofmann wrote:
On Thu, Apr 17, 2008 at 08:53:23AM -0400, Jorge Arellano Cid wrote:
On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote:
Hi Jorge,
On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote:
Hi Johannes,
On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote:
Hi Jeremy,
On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote:
On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote:
> Attached is a patch that enables double buffering for partial screen > redraws (this is where the flickering is most annoying). You will > need at least version r6079 of fltk2 to test.
OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run?
Mostly I would be interested whether it still feels fast. And any regressions you observe, of course...
I found something that looks like a bug in double buffering (it doesn't happen with the previous code).
If you:
- ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page.
You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL.
Please give it a look.
Patch 1 should fix the problem.
Good!
Committed.
The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part.
I'd commit bracketed as:
#ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif
[Drawing code here...]
#ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif
Would it be OK?
Yes, of course.
Committed. -- Cheers Jorge.-
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org