On Sat, Oct 13, 2007 at 05:04:19PM +0200, Matthias Franz wrote:
On Fri, Oct 12, 2007 at 10:28:38PM +0200, Johannes Hofmann wrote:
So could it be that it has to do with RENDER and that most of you have decent hadware acceleration for that?
Yes, I guess that's the reason. You can compile fltk with the --disable-xft flag. In this case you will get the artefacts you mentioned before, but the performance should be similar to dillo1.
I've compiled fltk with "--disable-xft". Now it doesn't use RENDER any more (checked with xtrace). But I don't notice any performance difference to dillo2 with xft. In particular, performance is far from being that of dillo1. So, xft / RENDER does not seem to be the reason. Maybe a detailed comparison of the xtrace logs of dillo1 and dillo2-noxft could help? I've seen that dillo2 uses many "ChangeGC", "SetClipRectangles" and "PolyFillRectangle" requests, which are not used by dillo1. I don't know which requests are particularly expensive.
AFAIR, dillo2 was passing trough the whole widget tree instead of just the to-be-rendered part. We were testing with Sebastian and optimizations were postponed. I also see a huge difference between dillo1 and dillo2. When Sebastian gets some free time he'll probably comment on that issue. If a simple but long FLTK2 widget can be scrolled with the same technique as in dillo2, with the same performance (or close) to dillo1, we'd know it is a bug within dw2. If not, we may ask in FKTK-dev. BTW, I preferred to take patches for dw2 and to commit them to CVS instead of pushing them for Sebastian to examine. That way he can catch up later while the patches improve. -- Cheers Jorge.-