Hi Johannes, On Tue, Nov 06, 2007 at 08:51:15PM +0100, Johannes Hofmann wrote:
Hi,
here is a patch to avoid the flickering even with clear_double_buffer() as currently in CVS. It uses a self-made double buffering for those drawing operations that need it (as it was done in dillo1). The main advantage over generally switching on double buffering, is that we need only one buffer for all windows, which saves X-server side memory and avoids slowdowns with many open windows.
Yes, and it works much better than what we have now...
However this approach has some drawbacks:
* The newly introduced FltkOffscreen class contains X11 specific code and it would be better if this could be done by fltk. But unfortunately there is an open bug (http://www.fltk.org/str.php?L1042).
Yes. One of the main advanteges of relying completely on fltk2 for drawing is that porting fltk2 to a new backend, makes dillo2 automatically work there too. Some people long for OpenGl, others the framebuffer, etc.
* When you compile fltk with the --disable-xft option you now need to do "export CPPFLAGS=-DNO_XFT" before configuring dw-testbed.
`fltk2-config --ldflags` reports on "-lXft". Maybe it can be used in configure.in as a test and thus, set CPPFLAGS automatically.
* It makes the redraws invisible again, which we might want to reduce by other means.
Yes, this is the key point. The main reason of leaving double buffering out is to remember that drawing needs an urgent fix. The number of redraws is not acceptable, and double buffering conceals it. I understand the need to reduce the annoying flickering, and huge memory footprint, but hesitate to commit the patch as is because it could stop people from porting fltk2 to a new backend when they need a browser. If you can add it as a compile time option (e.g. --with-internal-buffering) and automate the CPPFLAGS setting from configure, I'd commit. Now, what I'd really like is to reduce the number of redraws (an ugly bug) and to have an fltk2 means to make calls to X11. If you can work on the first task, it's more than welcomed. For the second one we need to coordinate with the fltk2 team. What do you think of this?
Jorge, regardless of whether you want to apply this patch, could you please apply the
@@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect { /** \bug Inefficient */
- push_clip( - translateCanvasXToViewX (area->x), - translateCanvasYToViewY (area->y), - area->width, - area->height); - redraw (DAMAGE_EXPOSE); - - pop_clip(); }
part, which removes some calls added with my initial scrolling patch. These calls are just wrong. push_clip/pop_clip can only be called from within the draw() method.
Out of place push/pop pair removal, commited. -- Cheers Jorge.-