[interfacekit] Re: :) Again - BBitmap

On Thu, 24 Jul 2003 01:10:24 +0300 "Adi Oanca" <adioanca@xxxxxxxxxxxxx>
 wrote:
>     To clear some things from the beginning.
> 
>     I know something about graphic cards and how they work. 3 years 
> ago, I
> intensively studied for 4 months DirectX API (the graphics part - 2D&
> 3D),
> and did some programming with it. Since then, I've constantly 
> monitored the
> new features of the new graphic cards as well as those of the APIs.

Good to know.

>     I can tell you one thing for sure: graphic cards do not render 
> into main
> memory! Not even those that use some of the main memory(those that 
> are
> integrated into the mainboard chipset)!

OK.

>     They can communicate with the main memory very fast through the 
> AGP
> port, but that is mainly used by APIs (DirectX | OpenGL) to transfer
> data(bitmaps & vertex data) from the main to video card memory when 
> it is
> needed.
> <my opinion>
>     Unfortunately, for the time being, this is one thing that our 
> app_server
> must to - take the place of a game API - in order to achieve 
> FORMIDABLE
> results. I say - for the time being, because, I bet that for the R3, 
> R4 the
> latest, our app_server will use OpenGL for rendering/clipping, and 
> who
> knows, maybe T&L (Transform(ation)&Lighting) for some amazingly 
> effects. :-)
> </my opinion>
> 
>     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?

> >(though I believe, graphic cards
> > support overlay from RAM (not only from graphic card memory as the
> > BBitmap flags suggest)).
>     No, they do not! Overlays are bitmaps that stay in video card 
> memory. At
> present time, AFAIK, overlays cannot anywhere else but in video 
> memory,
> because of they are needed for fast clipping on every frame that it 
> is drawn
> onto screen.

I stand corrected.

> > 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. If 
the bitmap can be drawn-to hardware accelerated, then it is done by the 
app server, otherwise by the application, saving resources. And 
because, as you say, graphic cards cannot render into main memory, it 
would also solve the problem with our sliders, since they don't use (or 
don't need to use) off-screen bitmaps and hence would be drawn 
application side.

> > well be drawn-to application side, avoiding the communication (and
> > thread) overhead.
> 
>     The thread overhead problem we must resolve. Communication is not 
> a
> problem!
> 
> > BSliders in particular could use a private API
> 
>     I do not agree! We must provide a standard, that should be used 
> by
> everybody! BSliders have no reason to use a particular API!

I was thinking of something like a B_BITMAP_DRAW_BY_APPLICATION flag 
passed to the constructor, which would force all drawing operations for 
the bitmap to be executed application side. Private, basically only for 
the reason that we don't want to introduce new public APIs in R1. 
Anyway, that would be of interest only, if graphic cards could draw 
into main memory. Hence we can disregard it.

> Developers may
> want to use off-screen  bitmaps for their purposes also. what should 
> they
> do, contact us to provide them an API? No! one *damn good* API for 
> everyone.

I don't see what off-screen bitmaps have to do with that. API users can 
create off-screen bitmaps with R5 and shall be able to do so with our 
R1, too.

> > > 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. 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). Which as a nice side effect also has other 
advantages, like no communication overhead and a lower latency in the 
respective cases.

2) ... two proposals for limiting the number of app server threads 
spawned for bitmap drawing. In case 1) is employed, this would only 
concern off-screen bitmaps, since all other bitmaps would be rendered 
by the application. 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. At 
least I wouldn't nag, if whoever implements it would argue that way. 
But the proposed solutions are nicer options, of course.

3) ... the need for a solution of a real problem, which would be to 
raise the resource limits for the app server.

CU, Ingo

Other related posts: