Investigate using client-side instead of server-side drawing

[waddlesplash]

Presently, app_server does entirely server-side drawing. This has its advantages - e.g. remote_app_server, RemoteDesktop, etc. but also drawbacks - app_server crashes due to AGG bugs, hangs, system port exhaustion (by WebKit, mostly...), etc.

For R2 (or later), it would be nice to investigate and at least prototype a client-side rendering model that somehow preserved the benefits of server-side rendering (like remote app_server) as well as the benefits of client-side rendering.

Additionally, this might be a nice time to make our rendering layer totally abstract, which might mean we could add additional backends (like an OpenGL accelerated rasterizer, for instance...)

[pulkomandy]

Our rendering layer is already quite well abstracted.

I don't recall seeing any crashes caused by agg bugs. Do you have some bugreports to share? There is one case of hang (the bezier curve algorithm sometimes doesn't converge), but I would say we should rather fix this in agg, otherwise it would just hang the affected app rather than the affected window on app_server side.

Drawing on the client side comes with its own set of problems, such as locking the window thread while it performs drawing operations. It also makes little sense if after all, what you actually do is submit everything to the GPU anyway.

The port exhaustion problem is very specific, it is due to creating a lot (thousands) of off-screen views that render to BBitmap. This is indeed one case where drawing could be performed client-side, but for regular BWindow that is shown on screen, I'm not so sure. We could also remove the arbitrary limit on the number of ports and allocate them dinamically. Also, this was largely solved by Jua's rework which dramatically reduced the number of required offscreen views. The only way to reproduce it now is with some of the webkit tests which will create thousands of <canvas> elements, each with an offscreen view. And running just one of these isn't even enough, you need to run 4 of them at once + some other system activity to trigger the crash.

As for "rendering layer abstraction", I am not sure what you mean. There is already an abstraction layer inside app_server, and this is how the different rendering options are implemented: agg, remote, and the partially complete html5 one. We could add an OpenGL (or, that would make more sense, OpenVG) backend at that level.

Moving it client side means you map quite a lot of things to the application memory space (all bitmap buffers, etc). It will be easy to crash an app on a 32bit system because it runs out of memory space. So, while it solves some problems, it creates some others.

[waddlesplash]

Well, in the future, the app_server will probably be compositing instead of having a single draw buffer, so having two draw buffers in shared memory that are also accessed by the app_server would be how that worked. Then offscreen views don't require a connection to anywhere.

And all bitmap buffers are held by app_server at present, no? So doesn't it run into the same memory space problem on 32-bit?

I suppose most of this stuff can be more easily investigated once app_server is already compositing.

[SeanCollins]

This sounds like a Ticket for R2

[waddlesplash]

Right now it's in Unscheduled; it's not necessarily something that must happen in R2 (or ever).

[waddlesplash]

I think ultimately client-side drawing makes less sense than I thought it once did, and indeed we already have well-abstracted rendering systems. So, I am going to close this ticket, and we can revisit it in the future if somehow it becomes necessary or needed.