OSDev.org

willedwards wrote:On Symbian it was very rare to use bitmap-backed windows. Typically, the draw commands were buffered and sent via IPC to the Window Server, which then stored them. The Window Server could replay these command buffers to regenerate anything. This worked exceedingly well, and with a bit of proxying we were able to transparently embed the draw commands emitted by one app inside another. I touch on that in this old blog post: http://williamedwardscoder.tumblr.com/p ... in-android

It's an interesting approach to send the drawing commands, the only problem I see with that is that the applications are not really free to use whatever painting library they want. By just providing a RGBA buffer, applications can do with it what they want and must not rely on specific OS functions.

Were you part of the Symbian OS developer team? My props to you, even though it's not that much used anymore, I think it was great work.

max wrote:It's an interesting approach to send the drawing commands, the only problem I see with that is that the applications are not really free to use whatever painting library they want. By just providing a RGBA buffer, applications can do with it what they want and must not rely on specific OS functions.

+1 for the buffer idea. Unless you're going to implement all sorts of drawing libraries server-side, or allow a client to install its own library on the server (neither of which sounds like a good idea), a buffer is the way to go.

Nevertheless, installing libraries on the server sounds like an *interesting* idea, I wonder how one could establish an effective and flexible way to communicate with the library, whatever library it is, without massive security implications (bonus points for the server sandboxing the library without breaking it)...

onlyonemac wrote:

max wrote:It's an interesting approach to send the drawing commands, the only problem I see with that is that the applications are not really free to use whatever painting library they want. By just providing a RGBA buffer, applications can do with it what they want and must not rely on specific OS functions.

+1 for the buffer idea. Unless you're going to implement all sorts of drawing libraries server-side, or allow a client to install its own library on the server (neither of which sounds like a good idea), a buffer is the way to go.

Nevertheless, installing libraries on the server sounds like an *interesting* idea, I wonder how one could establish an effective and flexible way to communicate with the library, whatever library it is, without massive security implications (bonus points for the server sandboxing the library without breaking it)...

This would probably require something like Java's RMI. With such a prerequesite it would have both the advantages that willedwards pointed out and still allow applications to be free of choice. Yet the libraries most likely would have to be adjusted to conform with whatever framework performs the RMI calls. Nice idea though