[patch] improve scroll performance of dillo-fltk
Hi, below is an initial patch that improves scrolling performance of dillo-fltk by copying screen data instead of rerendering it. It's based on Scroll.cxx from fltk. The difference is noticeable mostly when scrolling large images especially within a remote X11 session. The newly introduced scrollDX / scrollDY could probabely be combined with the existing oldScrollX / oldScrollY variables. Regards, Johannes diff --git a/dw-testbed-0.0.43j/dw/fltkviewbase.cc b/dw-testbed-0.0.43j/dw/fltkviewbase.cc --- a/dw-testbed-0.0.43j/dw/fltkviewbase.cc +++ b/dw-testbed-0.0.43j/dw/fltkviewbase.cc @@ -54,18 +54,16 @@ void FltkViewBase::draw () Group::draw (); - if (damage () & DAMAGE_EXPOSE) { - setcolor (bgColor); - ::fltk::Rectangle rect (0, 0, w(), h()); - fillrect (rect); - - core::Rectangle area; - area.x = translateViewXToCanvasX (0); - area.y = translateViewYToCanvasY (0); - area.width = translateViewXToCanvasX (0 + w ()) - 0; - area.height = translateViewYToCanvasY (0 + h ()) - 0; - theLayout->expose (this, &area); - } + setcolor (bgColor); + ::fltk::Rectangle rect (0, 0, w(), h()); + fillrect (rect); + + core::Rectangle area; + area.x = translateViewXToCanvasX (0); + area.y = translateViewYToCanvasY (0); + area.width = translateViewXToCanvasX (0 + w ()) - 0; + area.height = translateViewYToCanvasY (0 + h ()) - 0; + theLayout->expose (this, &area); } core::ButtonState getDwButtonState () diff --git a/dw-testbed-0.0.43j/dw/fltkviewport.cc b/dw-testbed-0.0.43j/dw/fltkviewport.cc --- a/dw-testbed-0.0.43j/dw/fltkviewport.cc +++ b/dw-testbed-0.0.43j/dw/fltkviewport.cc @@ -131,8 +131,8 @@ void FltkViewport::hscrollbarChanged () { int oldScrollX = scrollX; scrollX = hscrollbar->value (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + scrollDX = scrollX - oldScrollX; + redraw (DAMAGE_SCROLL); updateCanvasWidgets (oldScrollX, scrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); } @@ -141,8 +141,8 @@ void FltkViewport::vscrollbarChanged () { int oldScrollY = scrollY; scrollY = vscrollbar->value (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + scrollDY = scrollY - oldScrollY; + redraw (DAMAGE_SCROLL); updateCanvasWidgets (scrollX, oldScrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); } @@ -163,6 +163,25 @@ void FltkViewport::layout () { theLayout->viewportSizeChanged (this, w(), h()); adjustScrollbarsAndGadgetsAllocation (); +} + +void FltkViewport::draw_area (void *data, const Rectangle& cr ) +{ + FltkViewport *vp = (FltkViewport*) data; + push_clip(cr); + + vp->FltkWidgetView::draw (); + + //draw_child (*hscrollbar); + //draw_child (*vscrollbar); + + for(Iterator <TypedPointer < ::fltk::Widget> > it = vp->gadgets->iterator (); + it.hasNext (); ) { + ::fltk::Widget *widget = it.getNext()->getTypedValue (); + vp->draw_child (*widget); + } + + pop_clip(); } void FltkViewport::draw () @@ -170,20 +189,16 @@ void FltkViewport::draw () int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; Rectangle cr (0, 0, w () - hdiff, h () - vdiff); - push_clip(cr); - - FltkWidgetView::draw (); - - //draw_child (*hscrollbar); - //draw_child (*vscrollbar); - - for(Iterator <TypedPointer < ::fltk::Widget> > it = gadgets->iterator (); - it.hasNext (); ) { - ::fltk::Widget *widget = it.getNext()->getTypedValue (); - draw_child (*widget); - } - - pop_clip(); + int d = damage(); + + if (d == DAMAGE_SCROLL) { + scrollrect(cr, -scrollDX, -scrollDY, draw_area, this); + } else { + draw_area(this, cr); + } + + scrollDX = 0; + scrollDY = 0; } int FltkViewport::handle (int event) @@ -205,8 +220,9 @@ int FltkViewport::handle (int event) case PageUpKey: oldScrollY = scrollY; scrollY -= vscrollbar->pagesize (); + scrollDY = scrollY - oldScrollY; adjustScrollbarValues (); - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_SCROLL); updateCanvasWidgets (scrollX, oldScrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); return 1; @@ -214,8 +230,9 @@ int FltkViewport::handle (int event) case PageDownKey: oldScrollY = scrollY; scrollY += vscrollbar->pagesize (); + scrollDY = scrollY - oldScrollY; adjustScrollbarValues (); - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_SCROLL); updateCanvasWidgets (scrollX, oldScrollY); theLayout->scrollPosChanged (this, scrollX, scrollY); return 1; @@ -254,12 +271,13 @@ void FltkViewport::scrollTo (int x, int void FltkViewport::scrollTo (int x, int y) { int oldScrollX = scrollX; - //int oldScrollY = scrollY; + int oldScrollY = scrollY; scrollX = x; scrollY = y; + scrollDX = scrollX - oldScrollX; + scrollDY = scrollY - oldScrollY; adjustScrollbarValues (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_SCROLL); updateCanvasWidgets (oldScrollX, scrollY); } diff --git a/dw-testbed-0.0.43j/dw/fltkviewport.hh b/dw-testbed-0.0.43j/dw/fltkviewport.hh --- a/dw-testbed-0.0.43j/dw/fltkviewport.hh +++ b/dw-testbed-0.0.43j/dw/fltkviewport.hh @@ -20,6 +20,7 @@ private: enum { SCROLLBAR_THICKNESS = 15 }; int scrollX, scrollY; + int scrollDX, scrollDY; ::fltk::Scrollbar *vscrollbar, *hscrollbar; @@ -35,6 +36,7 @@ private: static void vscrollbarCallback (Widget *vscrollbar, void *viewportPtr); void updateCanvasWidgets (int oldScrollX, int oldScrollY); + static void draw_area (void *data, const Rectangle& cr); protected: int translateViewXToCanvasX (int x);
Hello, here is a new version of dillo-fltk scroll performance improvements. This patch is against vanilla dillo-fltk. New in this patch: * Hotkey bindings for arrow keys, Home- and EndKey. This only works when the focus is on the display area. * Only unclipped area is exposed which improves performance on large pages (e.g. http://www.w3.org/TR/xslt). * Limit scrolling to reasonable values. Regards, Johannes diff --git a/dw-testbed-0.0.43j/dw/fltkviewbase.cc b/dw-testbed-0.0.43j/dw/fltkviewbase.cc --- a/dw-testbed-0.0.43j/dw/fltkviewbase.cc +++ b/dw-testbed-0.0.43j/dw/fltkviewbase.cc @@ -50,22 +50,24 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { - /** \bug Somehow, the area, which is to be redrawn, should be regarded. */ - Group::draw (); - if (damage () & DAMAGE_EXPOSE) { - setcolor (bgColor); - ::fltk::Rectangle rect (0, 0, w(), h()); - fillrect (rect); - - core::Rectangle area; - area.x = translateViewXToCanvasX (0); - area.y = translateViewYToCanvasY (0); - area.width = translateViewXToCanvasX (0 + w ()) - 0; - area.height = translateViewYToCanvasY (0 + h ()) - 0; - theLayout->expose (this, &area); - } + ::fltk::Rectangle rect (x(), y(), w(), h()); + + /* fltk-clipping seems not to use widget coordinates */ + ::fltk::intersect_with_clip(rect); + rect.x(rect.x() - x()); + rect.y(rect.y() - y()); + + setcolor (bgColor); + fillrect (rect); + + core::Rectangle area; + area.x = translateViewXToCanvasX (rect.x()); + area.y = translateViewYToCanvasY (rect.y()); + area.width = rect.w(); + area.height = rect.h(); + theLayout->expose (this, &area); } core::ButtonState getDwButtonState () @@ -222,7 +224,16 @@ void FltkViewBase::queueDraw (core::Rect void FltkViewBase::queueDraw (core::Rectangle *area) { /** \bug Inefficient */ + + push_clip( + translateCanvasXToViewX (area->x), + translateCanvasYToViewY (area->y), + area->width, + area->height); + redraw (DAMAGE_EXPOSE); + + pop_clip(); } void FltkViewBase::queueDrawTotal () diff --git a/dw-testbed-0.0.43j/dw/fltkviewport.cc b/dw-testbed-0.0.43j/dw/fltkviewport.cc --- a/dw-testbed-0.0.43j/dw/fltkviewport.cc +++ b/dw-testbed-0.0.43j/dw/fltkviewport.cc @@ -129,22 +129,12 @@ void FltkViewport::adjustScrollbarValues void FltkViewport::hscrollbarChanged () { - int oldScrollX = scrollX; - scrollX = hscrollbar->value (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); - updateCanvasWidgets (oldScrollX, scrollY); - theLayout->scrollPosChanged (this, scrollX, scrollY); + scroll (hscrollbar->value () - scrollX, 0); } void FltkViewport::vscrollbarChanged () { - int oldScrollY = scrollY; - scrollY = vscrollbar->value (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); - updateCanvasWidgets (scrollX, oldScrollY); - theLayout->scrollPosChanged (this, scrollX, scrollY); + scroll (0, vscrollbar->value () - scrollY); } void FltkViewport::vscrollbarCallback (Widget *vscrollbar, void *viewportPtr) @@ -163,6 +153,25 @@ void FltkViewport::layout () { theLayout->viewportSizeChanged (this, w(), h()); adjustScrollbarsAndGadgetsAllocation (); +} + +void FltkViewport::draw_area (void *data, const Rectangle& cr ) +{ + FltkViewport *vp = (FltkViewport*) data; + push_clip(cr); + + vp->FltkWidgetView::draw (); + + //draw_child (*hscrollbar); + //draw_child (*vscrollbar); + + for(Iterator <TypedPointer < ::fltk::Widget> > it = vp->gadgets->iterator (); + it.hasNext (); ) { + ::fltk::Widget *widget = it.getNext()->getTypedValue (); + vp->draw_child (*widget); + } + + pop_clip(); } void FltkViewport::draw () @@ -170,26 +179,20 @@ void FltkViewport::draw () int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; Rectangle cr (0, 0, w () - hdiff, h () - vdiff); - push_clip(cr); - - FltkWidgetView::draw (); - - //draw_child (*hscrollbar); - //draw_child (*vscrollbar); - - for(Iterator <TypedPointer < ::fltk::Widget> > it = gadgets->iterator (); - it.hasNext (); ) { - ::fltk::Widget *widget = it.getNext()->getTypedValue (); - draw_child (*widget); - } - - pop_clip(); + int d = damage(); + + if (d == DAMAGE_SCROLL) { + scrollrect(cr, -scrollDX, -scrollDY, draw_area, this); + } else { + draw_area(this, cr); + } + + scrollDX = 0; + scrollDY = 0; } int FltkViewport::handle (int event) { - int oldScrollY; - switch(event) { case ::fltk::FOCUS: /** \bug Draw focus box. */ @@ -200,24 +203,37 @@ int FltkViewport::handle (int event) return 1; case ::fltk::SHORTCUT: - /** \bug Checks for scrollX and scrollY? */ switch (::fltk::event_key()) { case PageUpKey: - oldScrollY = scrollY; - scrollY -= vscrollbar->pagesize (); - adjustScrollbarValues (); - redraw (DAMAGE_EXPOSE); - updateCanvasWidgets (scrollX, oldScrollY); - theLayout->scrollPosChanged (this, scrollX, scrollY); + scroll (0, -vscrollbar->pagesize ()); return 1; case PageDownKey: - oldScrollY = scrollY; - scrollY += vscrollbar->pagesize (); - adjustScrollbarValues (); - redraw (DAMAGE_EXPOSE); - updateCanvasWidgets (scrollX, oldScrollY); - theLayout->scrollPosChanged (this, scrollX, scrollY); + scroll (0, vscrollbar->pagesize ()); + return 1; + + case DownKey: + scroll (0, (int) vscrollbar->linesize ()); + return 1; + + case UpKey: + scroll (0, (int) -vscrollbar->linesize ()); + return 1; + + case RightKey: + scroll ((int) hscrollbar->linesize (), 0); + return 1; + + case LeftKey: + scroll ((int) -hscrollbar->linesize (), 0); + return 1; + + case HomeKey: + scrollTo (0, 0); + return 1; + + case EndKey: + scrollTo (canvasWidth, canvasHeight); /* gets adjusted in scroll() */ return 1; } @@ -251,16 +267,46 @@ int FltkViewport::getVScrollbarThickness return SCROLLBAR_THICKNESS; } +void FltkViewport::scroll (int dx, int dy) +{ + int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; + int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; + int oldScrollX = scrollX; + int oldScrollY = scrollY; + + if (dx == 0 && dy == 0) { + return; + } + + scrollX += dx; + scrollY += dy; + + if (scrollX > canvasWidth - w() + hdiff) { + scrollX = canvasWidth - w() + hdiff; + } + if (scrollX < 0) { + scrollX = 0; + } + + if (scrollY > canvasHeight - h() + vdiff) { + scrollY = canvasHeight - h() + vdiff; + } + if (scrollY < 0) { + scrollY = 0; + } + + scrollDX = scrollX - oldScrollX; + scrollDY = scrollY - oldScrollY; + + adjustScrollbarValues (); + redraw (DAMAGE_SCROLL); + updateCanvasWidgets (oldScrollX, oldScrollY); + theLayout->scrollPosChanged (this, scrollX, scrollY); +} + void FltkViewport::scrollTo (int x, int y) { - int oldScrollX = scrollX; - //int oldScrollY = scrollY; - scrollX = x; - scrollY = y; - adjustScrollbarValues (); - /** \bug Inefficient */ - redraw (DAMAGE_EXPOSE); - updateCanvasWidgets (oldScrollX, scrollY); + scroll (x - scrollX, y - scrollY); } void FltkViewport::setViewportSize (int width, int height, diff --git a/dw-testbed-0.0.43j/dw/fltkviewport.hh b/dw-testbed-0.0.43j/dw/fltkviewport.hh --- a/dw-testbed-0.0.43j/dw/fltkviewport.hh +++ b/dw-testbed-0.0.43j/dw/fltkviewport.hh @@ -20,6 +20,7 @@ private: enum { SCROLLBAR_THICKNESS = 15 }; int scrollX, scrollY; + int scrollDX, scrollDY; ::fltk::Scrollbar *vscrollbar, *hscrollbar; @@ -35,6 +36,7 @@ private: static void vscrollbarCallback (Widget *vscrollbar, void *viewportPtr); void updateCanvasWidgets (int oldScrollX, int oldScrollY); + static void draw_area (void *data, const Rectangle& cr); protected: int translateViewXToCanvasX (int x); @@ -55,6 +57,7 @@ public: bool usesViewport (); int getHScrollbarThickness (); int getVScrollbarThickness (); + void scroll(int dx, int dy); void scrollTo (int x, int y); void setViewportSize (int width, int height, int hScrollbarThickness, int vScrollbarThickness);
On Mon, Oct 08, 2007 at 08:01:14PM +0200, Johannes Hofmann wrote:
* Hotkey bindings for arrow keys, Home- and EndKey.
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load. A question: Would it be difficult to add mouse wheel support as well? On my machine that does not work. (Or is thia a configuration issue regarding FLTK?) Thanks in advance, -- Matthias Franz
On Mon, Oct 08, 2007 at 10:23:22PM +0200, Matthias Franz wrote:
On Mon, Oct 08, 2007 at 08:01:14PM +0200, Johannes Hofmann wrote:
* Hotkey bindings for arrow keys, Home- and EndKey.
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
It is slow, because the default linesize (the amount a scrollbar scrolls when pushing on the arrow is 1. I could change that, but what would be a reasonable value? Apart from that it should not consume all CPU time. It doesn't here. On which html page do you test? Is it in a remote X11 session? It might perhaps depend on the keyboard repeat rate. Does it also happen, when you keep the arrow on the scrollbar pressed?
A question: Would it be difficult to add mouse wheel support as well? On my machine that does not work. (Or is thia a configuration issue regarding FLTK?)
No it's just some missing code. Johannes
Thanks in advance, -- Matthias Franz
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Tue, Oct 09, 2007 at 05:25:09PM +0200, Johannes Hofmann wrote:
On Mon, Oct 08, 2007 at 10:23:22PM +0200, Matthias Franz wrote:
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
It is slow, because the default linesize (the amount a scrollbar scrolls when pushing on the arrow is 1. I could change that, but what would be a reasonable value? Apart from that it should not consume all CPU time. It doesn't here. On which html page do you test?
It occurs on any page where you can scroll.
Is it in a remote X11 session?
no
It might perhaps depend on the keyboard repeat rate.
I think my keyboard rate is normal.
Does it also happen, when you keep the arrow on the scrollbar pressed?
Yes. It happens as well when you move the scrollbar with the mouse (while pressing the left mouse button). Today I noticed that other features of dillo-fltk are also slower than before. For example, I get approximately a 50% CPU load just by moving the pointer repeatedly back and forth over a link so that the pointer constantly changes from the "arrow" shape to the "hand" shape and back. When I do this with the old dillo the CPU load remains around zero. (I have an AMD Athlon prcessor running at 660 MHz.) I don't know whether this is a problem with dillo, fltk or just with my machine (Debian Etch). Do other people observe this problem as well? Cheers, -- Matthias Franz
On Tue, Oct 09, 2007 at 07:29:46PM +0200, Matthias Franz wrote:
On Tue, Oct 09, 2007 at 05:25:09PM +0200, Johannes Hofmann wrote:
On Mon, Oct 08, 2007 at 10:23:22PM +0200, Matthias Franz wrote:
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
It is slow, because the default linesize (the amount a scrollbar scrolls when pushing on the arrow is 1. I could change that, but what would be a reasonable value? Apart from that it should not consume all CPU time. It doesn't here. On which html page do you test?
It occurs on any page where you can scroll.
Is it in a remote X11 session?
no
It might perhaps depend on the keyboard repeat rate.
I think my keyboard rate is normal.
Does it also happen, when you keep the arrow on the scrollbar pressed?
Yes. It happens as well when you move the scrollbar with the mouse (while pressing the left mouse button).
Here it gets down to 10% idle when keeping the arrow pressed with vanilla dillo-fltk. With my patch it stays at 99% idle. This is on a Pentium-M forced down to 600MHz.
Today I noticed that other features of dillo-fltk are also slower than before. For example, I get approximately a 50% CPU load just by moving the pointer repeatedly back and forth over a link so that the pointer constantly changes from the "arrow" shape to the "hand" shape and back. When I do this with the old dillo the CPU load remains around zero. (I have an AMD Athlon prcessor running at 660 MHz.) I don't know whether this is a problem with dillo, fltk or just with my machine (Debian Etch).
It might have to do with your X11 installation or Xft configuration. Do you see antialiased fonts?
Do other people observe this problem as well?
Cheers, -- Matthias Franz
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Tue, Oct 09, 2007 at 08:09:48PM +0200, Johannes Hofmann wrote:
On Tue, Oct 09, 2007 at 07:29:46PM +0200, Matthias Franz wrote:
On Tue, Oct 09, 2007 at 05:25:09PM +0200, Johannes Hofmann wrote:
Does it also happen, when you keep the arrow on the scrollbar pressed?
Yes. It happens as well when you move the scrollbar with the mouse (while pressing the left mouse button).
Here it gets down to 10% idle when keeping the arrow pressed with vanilla dillo-fltk. With my patch it stays at 99% idle.
It might have to do with your X11 installation or Xft configuration. Do you see antialiased fonts?
I didn't have the development files for Xft installed!!! I've installed them, and now dillo-fltk uses antialiased fonts. The problem still remains, though. Heavy CPU load for scrolling or just moving the pointer across links. No difference between vanilla dillo-fltk and the patched version. Massive difference to the old dillo. -- Matthias Franz
On Tue, Oct 09, 2007 at 05:25:09PM +0200, Johannes Hofmann wrote:
On Mon, Oct 08, 2007 at 10:23:22PM +0200, Matthias Franz wrote:
It is slow, because the default linesize (the amount a scrollbar scrolls when pushing on the arrow is 1. I could change that, but what would be a reasonable value? Apart from that it should not consume all CPU time. It doesn't here. On which html page do you test?
It occurs on any page where you can scroll.
Speaking of scrolling, if I hold down PageDown or PageUp, a large page of text often can't keep up. The scrollbar will be, say, at the extreme bottom, but the text might stop around the 80% mark.
Today I noticed that other features of dillo-fltk are also slower than before. For example, I get approximately a 50% CPU load just by moving the pointer repeatedly back and forth over a link so that the pointer constantly changes from the "arrow" shape to the "hand" shape and back. When I do this with the old dillo the CPU load remains around zero. (I have an AMD Athlon prcessor running at 660 MHz.) I don't know whether this is a problem with dillo, fltk or just with my machine (Debian Etch).
Do other people observe this problem as well?
Now that I know to look for it, yes. It seems to depend on how large the textblock is that I move over. Commenting out Textblock::motionNotifyImpl() made no difference, and I don't know the upstream code well enough yet to chase down the problem efficiently...
Hi, On Mon, Oct 08, Matthias Franz wrote:
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
Just to save your time for investigating this further: This is a known problem. Generally, the GTK-based dillo drew only the part of the viewport, which was really needed, e.g. - scrolling was optimized, by copying one part, and redrawing only the formerly invisibly part (IIRC, this was done mostly by GTKLayout), - small redraw requests (changing the color of a link, drawing one line of an image ...) resulted in drawing of actually small areas, - etc. This is not yet implemented in FLTK, due to the worse support by FLTK, which seems only to support redrawing of whole widgets. (And from the view of FLTK, the viewport is simply one FLTK widget.) For this reason, any redraw request results in redrawing the whole viewport area, which is of course horribly inefficient. In the documentation, there is a list of known problems with FLTK, available at dw-testbed-0.0.47/html/fltk-problems.html (after running doxygen). Anyone, which is a bit familiar with this, is invited to investigate this problem (and the other ones) further. (The "core" of Dw is already prepared, it is just a problem of connecting it to the FLTK-specific code.) When I'm just at it:
A question: Would it be difficult to add mouse wheel support as well? On my machine that does not work. (Or is thia a configuration issue regarding FLTK?)
Scrolling is completely done by Dw (or, the FLTK part of Dw), so it is, as Johannes already mentioned, missing code. I do not know how scrolling wheel events are handled, but once this problem is solved, it should be simple to add. Sebastian
Hi Sebastian, first of all thanks for your great work! On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote:
Hi,
On Mon, Oct 08, Matthias Franz wrote:
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
Just to save your time for investigating this further: This is a known problem. Generally, the GTK-based dillo drew only the part of the viewport, which was really needed, e.g.
- scrolling was optimized, by copying one part, and redrawing only the formerly invisibly part (IIRC, this was done mostly by GTKLayout),
This is already implemented in dillo-fltk from cvs. But gtk1 seems to use an even faster approach. I think they use XMoveWindow() instead of XCopyArea() for most part of the window, which seems to be faster especially on some older machines. Johannes
Hi On Sun, Oct 14, 2007 at 07:54:23PM +0200, Johannes Hofmann wrote:
Hi Sebastian,
first of all thanks for your great work!
On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote:
Hi,
On Mon, Oct 08, Matthias Franz wrote:
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
Just to save your time for investigating this further: This is a known problem. Generally, the GTK-based dillo drew only the part of the viewport, which was really needed, e.g.
- scrolling was optimized, by copying one part, and redrawing only the formerly invisibly part (IIRC, this was done mostly by GTKLayout),
This is already implemented in dillo-fltk from cvs. But gtk1 seems to use an even faster approach. I think they use XMoveWindow() instead of XCopyArea() for most part of the window, which seems to be faster especially on some older machines.
You can try FLTK2-r5941 (weekly stable). With that version we can ask in fltk-dev for details. -- Cheers Jorge.-
On Sun, Oct 14, 2007 at 04:27:59PM -0300, Johannes Hofmann wrote:
Hi
On Sun, Oct 14, 2007 at 07:54:23PM +0200, Johannes Hofmann wrote:
Hi Sebastian,
first of all thanks for your great work!
On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote:
Hi,
On Mon, Oct 08, Matthias Franz wrote:
Fine! Only using the arrow keys is quite slow and consumes all CPU time on my machine. In contrast, srolling with the old Dillo was quick and produced almost no CPU load.
Just to save your time for investigating this further: This is a known problem. Generally, the GTK-based dillo drew only the part of the viewport, which was really needed, e.g.
- scrolling was optimized, by copying one part, and redrawing only the formerly invisibly part (IIRC, this was done mostly by GTKLayout),
This is already implemented in dillo-fltk from cvs. But gtk1 seems to use an even faster approach. I think they use XMoveWindow() instead of XCopyArea() for most part of the window, which seems to be faster especially on some older machines.
You can try FLTK2-r5941 (weekly stable). With that version we can ask in fltk-dev for details.
It's the same with FLTK2-r5941. However what fltk does for scrolling is pretty sensible. We might still switch to a scrolling scheme similar to gtk1 if someone understands what exactly gtk1 is doing and why it is faster. Johannes
participants (6)
-
bogus＠does.not.exist.com -
Johannes Hofmann -
Johannes.Hofmann＠gmx.de
-
Matthias Franz -
place -
sgeerken＠dillo.org