Linked by Thom Holwerda on Sat 23rd Dec 2006 00:48 UTC, submitted by dumbkiwi
KDE This is a response to the article yesterday on the progress of GNOME and KDE. Aaron Seigo, a lead KDE developer, sets out the current state of progress with KDE 4, pointing out that KDE 4 is on track for a release in mid 2007. "Thom points to a quote from me that our goal is to have a 4.0 ready sometime in the first half of next year. That gives us until sometime in June and I'm still thinking we can make it."
E-mail Print r 37   87 Comment(s)
Thread beginning with comment 196057
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Regarding Arthur, I'm not conversant on its internal architecture, but I don't see why it should be any more difficult for it than for Cairo. The problem isn't Cairo or Arthur, but the rest of the stack. What Cairo/Arthur need is a way to get at the pixel shader hardware on the GPU.

I don't think that pixel shaders are responsibility of client-side (but are server side). if I understand correctly, problem is how to pass (Cairo, Arthur) vector data all to the compositing manager which can transform windows, and in fact is a good candidate to transform and rasterize vector data to screen (using pixel shaders!), so we can get DPI-independent and virtually aliasing-free view (i.e. no upsampling on zoom, well antialiased transformed fonts etc). It can contain shader programs to do high quality antialiasing of vector primitives.

I'd say there IS a problem with Arthur and Cairo. They don't (beyond X protocol part) send information about window structure or visibility of components. With server bitmaps you don't need this because new Xrender data will happily overwrite old bitmap when app decides to modify screen. Situation is however different if you e.g. want to rescale window without app knowing it. To perform this without artefacts, you'll have to replay whole vector data stream and rasterize it again at higher resolution, which can be a bottleneck if there is much data. This needs better handling of what is visible and what is flushed as no longer visible, to replay least possible amount of vector data on redraw. Either it can be done using complex scene definition which compositing manager can understand so it can cut out invisible parts, or by trusting application to be aware of the issue, so it notifies when old vector data stored in server can be dumped.

Of course most apps will have rather simple structure so this won't be much of an issue, but bad behaved app could potentially cause problems and generally it is always better to hide issues in the server (or toolkit) than to put additional burden on app developers.

Reply Parent Score: 1

rayiner Member since:

Sending a scene description to the server would solve the problem I'm talking about, but such a retained-mode design completely goes against the X architecture. The way to achieve resolution-independence within the existing X architecture is to retain the immediate-mode semantics, and do scaling with minimal cooperation from the toolkit. See XEvIE for the general model of how this would be done.

Reply Parent Score: 2