[interfacekit] Re: :) Again - BBitmap

On Thu, 24 Jul 2003 16:26:22 +0200 "Marc Flerackers" <
mflerackers@xxxxxxxxxx> wrote:
> I would like to mention that more then 50% of the app_server code is
> rendering code, not even including the font rendering API. If you 
> want to
> draw locally from the app, more than 50% of the app_server code will 
> go into
> libbe, which seems not so efficient memory wise.

At least the usage of physical memory shouldn't change. And since we'll 
hopefully be less restrictive regarding add-on/library size limits, I'd 
see no real harm here. And hey, it's not like the app server is dozens 
of MB big. ;-)

> Also please consider the consequences of not having the view 
> connected to
> the app_server, and not having a server counterpart. The connection 
> is not
> only used for drawing operations.

Mmh, what else is done for bitmaps?

> And making this change will have lots of
> other needed changes as a result.

I don't see, why that would be so, but it's certainly not my domain.

> Look for example at BPrintJob,
> BPrintJob::DrawView() needs the given view to be attached to a window
> because the drawing commands need to reach the app_server. "The view 
> must be
> attached to a window; that is, it must be known to the Application 
> Server."

I fail to get what BPrintJob has to do with bitmap drawing.

> If I would change it (although I wouldn't, because I really don't see 
> a
> problem with how it's done now)

Aside from that it is very heavy weight, it is very restrictive, that 
you have to decide on construction, whether you later want to draw into 
a bitmap or not, and also pragmatically weird (one adds views to a 
bitmap, huh?). This makes e.g. mapping a saner framework like Qt to 
that API very ugly.

> I would write an API like the BPicture one,
> a BeginDrawBitmap(bitmap) and EndDrawBitmap(). All the drawing 
> instructions
> received between those calls would be rendered into the bitmap 
> instead of
> the window. This would make a lot of sense, since you would most 
> likely call
> view->Draw(view->Bounds()) from a window thread anyway, so why not 
> let that
> server thread do the work?

Though I don't get the last part, I think, this is better than the R5 
API, since it addresses at least two of my points. It's still heavy 
weight though, since you always need a window, when you want to draw 
something into a bitmap. If a window is at hand anyway, one could 
create a hidden dummy view, which is not nice but saves resources.

To sum up this thread a bit from my point of view: The problem is, that 
bitmaps that accept views occupy resources in the app server -- most 
notably a thread for each -- which lets the app server get into 
trouble, when a lot of them are created (e.g. by using BSliders). To 
solve the problem Adi came up with an approach to limit the resources 
and share them among the bitmaps (and I proposed a slightly different 
variant). Certainly a good idea, though probably not completely trivial 
to implement. A simpler approach would be to move the drawing code for 
bitmaps into libbe -- which, if I understood DW correctly, shouldn't be 
a problem -- and do the drawing into non-off-screen bitmaps on the 
application side. It actually doesn't completely solve the problem, 
since one could still create lots of off-screen bitmaps, but, I 
suspect, it's very unlikely to happen in practice.

Anyway, I don't work on the app server related parts and freely admit, 
that I have very little knowledge about how it works. So, please feel 
free to ignore my humble opinion.

CU, Ingo

Other related posts: