EVALUATION
Well, after investigating this a little I found that the performance regressed
about 15-20x. I looked into the code a little and added some timing code. It
ends up that setXORMode has regressed. I'm talking to the 2D group to look for
a workaround.
###@###.### 2002-05-16
The 2D code apparently hasn't regressed it's the time it takes to send requests
to the xserver. Looking into why this code regressed.
###@###.### 2002-06-10
According to Jim, XOR is now being done in software. We need to add platform
acceleration back in.
###@###.### 2002-07-11
I'm committing to fix this in mantis rather than tiger since it's a serious
regression for customers. The fix is as described above: reinstate platform
rendering for XOR mode (using X11 on Solaris, Linux; GDI on Windows). With this
fix in place, users on both platforms should see XOR performance improve back
equal to or better than 1.3.1 performance. This is significant for Windows
users, because XOR performance on that platform dropped tenfold between 1.4.0
and 1.4.1 (see 4711587).
###@###.### 2002-10-01
Platform (GDI/X11) XOR rendering code has been added back in, and as a result
the ~70x regression on Windows and the ~10x regression on Solaris/Linux have
been eliminated. Therefore, XOR performance when rendering to the screen is
back to 1.3.1 levels. I've verified these performance gains with the attached
testcase and in Metalworks (with outline drag mode enabled, dragging/resizing
is very responsive again).
###@###.### 2002-10-25
|