[interfacekit] Re: :) Again - BBitmap

On Thu, 24 Jul 2003 12:30:19 +0300 "Adi Oanca" <adioanca@xxxxxxxxxxxxx>
 wrote:
[...]
> > >     I will talk and talk ... and talk about this until you all 
> > > agree
> > > to
> > > render into bitmaps on the server-side, because sooner or later, 
> > > I'm
> > > sure
> > > that we will do that because of the hardware acceleration. WE 
> > > MUST do
> > > that,
> > > I've already told you, OS X uses OpenGL to render its UI, Windows
> > > will use
> > > DirectX to do that. WE MUST follow them, WE MUST say in sync with 
> > > the
> > > times!!!!!!!!!!!!!!!!
> >
> > Sure, noone argues against drawing into bitmap for which hardware
> > acceleration would be available on app server side (off-screen 
> > bitmaps
> > for now). But I don't see the point in drawing every bitmap there. 
> > If
> > current graphic cards can't draw into main memory, then why should 
> > the
> > app server do the drawing, when we can save a thread, communication
> > overhead, and latency (less context switching) by drawing 
> > application
> > side?
> 
>     Latency? Please explain. All I can say, is that, we can lower to 
> 0 the
> time we wait for the (main thread)/(one thread) in my/your solution.

If two threads are involved in drawing to the bitmap at least two 
context switches are necessary until the bitmap is drawn and the 
application thread can resume its work (latency). Moreover two or more 
syscalls are done for the communication (yes, that's not really 
critical).

>     "Why should the app_server do the drawing"? I'll give you one (I 
> might
> say DAMN) good reason. SPEED! I am ready to make a bet: we make a 
> test with
> the drawing being made server-side vs. drawing being made app-side, 
> for
> about a minimum of... 50 drawing instructions. I have no doubt that 
> the
> server will get the crown - with all the communication and a new 
> thread
> being spawned! Then... imagine for 200, 400 d. i.... a BIG difference 
> will
> appear. THAT IS WHY accelerated hardware exists!!! As an example: try
> running Quake I in software rendering mode vs. running it on the 
> latest
> generations graphic cards - AND note that the T&L engine won't be 
> used...
> only "raw" rendering... and ALSO note in software rendering d. i.s 
> are
> optimized for speed - that's why it looks ugly.

Come on, you didn't read what I wrote. In the proposed approach the app 
server would do the drawing in cases where hardware acceleration is 
available, but the application would do it by itself, if it is not.

> > > > On the other hand, the implementation idea we discussed --
> > > > implementing
> > > > the BView drawing methods so that they allow for both 
> > > > application
> > > > side
> > > > and app server side drawing -- is flexible enough, I think.
> > >
> > >     Excuse me for how this sounds,but I can't find another way :-
> > > ).
> > > Flexible
> > > for what?
> >
> > For always only doing the work with the minimally possible 
> > overhead.
> 
>     This is not flexibility. :-) This is efficiency. :-)

It's the flexibility to be always most efficent. ;-)

>     :-) Flexible would be a fast drawing engine that can do 
> accelerated
> drawing onto screen as well as into bitmaps.

What I'm proposing still does that.

> > > > > I am
> > > > > asking you to come up with the best ideas you have!
> > >
> > >     OK, For now there are 2 ideas to solve out thread problem:
> > > MOOOOORE,
> > > PLS!
> > [...]
> > > COME ON PEOPLE! MORE IDEAS! THIS IS ONE BIG PROBLEM THAT *MUST* 
> > > BE
> > > SOLVED!
> >
> > Your enthusiasm is certainly appreciated, but I fail to see, what 
> > you
> > want more.
> 
>     Now that I finished the faculty, I will get employed. I'll go 
> into
> Bucharest and try to do (at Ubisoft) what I want to do in my
> life(programming side:-): create games. You must see the similarity 
> between
> this and a game:-). Because I want the best for this project I insist 
> for
> you to agree with me! :-)
> 
>     Because we have 2 methods, it doesn't mean that a better one 
> doesn't
> exist!

I wouldn't rule out that possibility, but realistically analyzing the 
situation, I wouldn't expect too much: The problem is, that for each 
bitmap accepting views the app server runs a separate thread, which 
causes too many threads to be spawned, when an application creates a 
lot of those bitmaps. The obvious solution is to limit the number of 
spawned threads, which at some point requires multiplexing of drawing 
operations for different bitmaps per thread. Our approaches do that 
both and the difference between them is basically, that you always 
multiplex to one thread and spawn a new thread, only when the work load 
for this thread becomes too bad, while my solution would only start 
multiplexing when more bitmaps are created than the maximal number of 
threads we allow. (That's why I like mine a bit better, BTW. ;-)

There might be slightly better strategies, but, as I said, I wouldn't 
expect too much. I think, it's at least not worth doing heavy 
optimization at this point. This is all completely transparent to the 
applications, hence we can optimize at any time later. For now I would 
concentrate on getting a reasonably good implementation at all.

> > We have
> >
> > 1) ... an idea for getting rid of all bitmap drawing app server 
> > thread
> > where they are not needed (in cases where no hardware acceleration
> > would be available).
> 
>     7 years have passed since the fist 3D card has appeared! I REALLY 
> don't
> think that there is someone who doesn't have one! And if it is... I 
> surely
> don't want to support his needs! This is a Multimedia OS, we have 
> some
> requirements, don't we?

Sure, I just don't see how this is related. You are talking about 3D 
acceleration, while I outlined a simple strategy, that can be used, in 
those cases (not `for those graphic cards') where hardware acceleration 
is not available. Which currently holds for all non-off-screen bitmaps, 
i.e. for almost all bitmaps being used (I assume that for BSliders, at 
least).

> > Which as a nice side effect also has other
> > advantages, like no communication overhead and a lower latency in 
> > the
> > respective cases.
> 
>     I repeat: Communication it's not an issue! And about the latency: 
> Don't
> worry, it's bigger when you draw onto screen (that is, if you don't 
> use a
> double buffer :-)!

Sure, that's why I called it a `nice side effect'.

> > One could even go so far to argue that it's the
> > responsibility of the developer then -- it's their own fault, when 
> > they
> > create 100 off-screen bitmaps and experience problems due to that.
> 
>     Well... I stand between... either way, we must provide the best 
> cost
> solution we can come up with.

We certainly will. Though I would prefer to have a good solution soon, 
than the best solution half a year later. Mind you, the current goal is 
to clone R5, extending and improving only where really needed or being 
done at very low cost.

CU, Ingo

Other related posts: