Opened 7 months ago

Last modified 4 months ago

#13195 assigned enhancement

Investigate using client-side instead of server-side drawing

Reported by: waddlesplash Owned by: nobody
Priority: low Milestone: Unscheduled
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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...)

Change History (5)

comment:1 Changed 7 months ago by 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.

comment:2 Changed 7 months ago by 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.

comment:3 Changed 7 months ago by SeanCollins

This sounds like a Ticket for R2

comment:4 Changed 7 months ago by waddlesplash

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

comment:5 Changed 4 months ago by axeld

  • Owner changed from axeld to nobody
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.