Re: fastest output
Andreas Beck wrote: > > quite extensively but as I heared, the visual structure itself > > is too complex to be used for that. > > Depends. For backing store of whole windows and such, I see no problem. > But for a few dozen sprites it's a bit heavy. However when you stuff the > sprites onto a single visual, I'd say that's o.k. as well. In my first attempts at porting Amulet last year (and in my current attemps also BTW), I used raw memory-visual for the backing store of windows. By default, Amulet applications uses windows double-buffering on all windows - and the copying overhead was not noticeable on such heavy-weight applications. (The CPU workload was noticeable however - but this should go away with hardware accelerator, so...) Of course, however, rendering speed was not at all a concern in a GUI library... :-) But globally, Andreas appreciation seems very accurate (as usual...;-). Rodolphe
RE: fastest output
Video memory writing usually is slower than computer memory. If you use video memory for drawing operation you have to pay for it. For example software alpha-blending in video memory is usually slower than the same operations in usual memory, but software blit from usual memory take more than page flipping and copy from video to video memory. So there is no true answer for all combination of drawing operation. Also we have to take in account using of accelerated functions. But often those functions are slower than software equivalents. Dmitry Semenov -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 29, 2000 03:11 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: fastest output Andreas Beck wrote: > > > what about a memory visual using video memory ? > > This can be done by using e.g. the "sub target" on a main visual with a > larger virtual area I don't understand. You ask me to allocate a larger visual and then to use the bytes currently not visible for my other purposes ? I think that is a bad idea. First of all, I don't know how many extra buffers I need. This is all dynamic. If a client connects to the server and asks for a graphic he can run his quicktime movie in, I want to back up everything behind and in front of it so I don't need to traverse the scene graph each time a new frame is rendered into this video graphic. In other words, the number and size of drawables I might want to allocate are completely arbitrary and only known at run time. Therefor I want a 'drawable manager' which is responsible for (V)RAM allocation and deallocation on demand. This might be more in line with what you refer to as an extension. I just want to remind you that we are (will be) quite keen on this. Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: fastest output
Andreas Beck wrote: > > > what about a memory visual using video memory ? > > This can be done by using e.g. the "sub target" on a main visual with a > larger virtual area I don't understand. You ask me to allocate a larger visual and then to use the bytes currently not visible for my other purposes ? I think that is a bad idea. First of all, I don't know how many extra buffers I need. This is all dynamic. If a client connects to the server and asks for a graphic he can run his quicktime movie in, I want to back up everything behind and in front of it so I don't need to traverse the scene graph each time a new frame is rendered into this video graphic. In other words, the number and size of drawables I might want to allocate are completely arbitrary and only known at run time. Therefor I want a 'drawable manager' which is responsible for (V)RAM allocation and deallocation on demand. This might be more in line with what you refer to as an extension. I just want to remind you that we are (will be) quite keen on this. Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: fastest output
> "I render into a buffer allocated with malloc. at the end i write > its content with a ggiPutBox to the graphics card (video-ram). > in my new design i use an a memory-visual instead of the own > buffer and do a ggiCrossBlit to a default-visual > => Speed up by factor 10." > i cannot believe this. > i really do not understand why this should be true. > i thought if i cannot get directbuffer the fastest way > is use malloced buffer and do ggiPutBox. > why should the CrossBlit be faster, even though it should > do EXACTLY the same ? I suppose he is comparing CrossBlit to the original situation. Putbox is generally faster than Crossblit from a memory visual. As explained in my other mail, Directbuffer can be slow as well due to the possibly slow bus that gets in the way if multiple accesses are done on the same pixel every frame. CU, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: fastest output
> i create pictures. let'S say from my own handcoded > 3D engine. it writes into a linear 8bit buffer. > but it overwrites quite often. > then i do some update function and want the picture on screen. > > until now i use directbuffers if possible and ggi_putbox if not. > > but couldn't it be that ggi_putpox is faster ??? Yes. Possible. Depends on a lot of factors. Relative Speed of VRAM/SysRAM access, how much acceleration is used and supported. > shouldn't i use ggi_putbox to write my internal buffer into > the directbuffer ? > is a directbuffer on the graphicscard behind the slow > ISA bus or is it in RAM It is not defined where the directbuffer is. With XShm it is in local RAM for example, with fbdev, it is on the graphics card. > what is fastest solution ? Making it an option and let the user or a timing loop select one. Using a memtarget, it is very easy to write code that does so. Basically it is: open_"real"_target(); open_rendertarget_as_configured(); if rendertarget==memory open_"real"_target(); render_to_rendertarget(); if rendertarget==memory copy_render-_to_"real"-target(); CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: fastest output
> what about a memory visual using video memory ? This can be done by using e.g. the "sub target" on a main visual with a larger virtual area > Which reminds me of a question I wanted to ask on the list here: > Are there any plans to create a visual like structure which's > only use is for caching a la double buffering or backing graphics ? Yes. this one goes with the blob and sprite extensions we haven been talking about a while ago. I even have a demo implementation of an extension that should handle both, but we decided to make it separate entities instead, but never got around to implement it. Got to pick that one up as well ... I really need those 127 hour days ... > quite extensively but as I heared, the visual structure itself > is too complex to be used for that. Depends. For backing store of whole windows and such, I see no problem. But for a few dozen sprites it's a bit heavy. However when you stuff the sprites onto a single visual, I'd say that's o.k. as well. > We really don't want event support or anything in this structure, Well it has event support, but only in the sense, that the hooks are there ... CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: fastest output
Erik Thiele wrote: > "I render into a buffer allocated with malloc. at the end i write > its content with a ggiPutBox to the graphics card (video-ram). > in my new design i use an a memory-visual instead of the own > buffer and do a ggiCrossBlit to a default-visual > => Speed up by factor 10." > > i cannot believe this. > i really do not understand why this should be true. > > i thought if i cannot get directbuffer the fastest way > is use malloced buffer and do ggiPutBox. > why should the CrossBlit be faster, even though it should > do EXACTLY the same ? what about a memory visual using video memory ? It's still offscreen but bitblit operations should be *much* faster. Which reminds me of a question I wanted to ask on the list here: Are there any plans to create a visual like structure which's only use is for caching a la double buffering or backing graphics ? We'd like to make use of such a data type in the berlin project quite extensively but as I heared, the visual structure itself is too complex to be used for that. We really don't want event support or anything in this structure, it's just a chunk of (hopefully video) memory. Then it's GGI's responsability to allocate the memory either from video (if available) or fall back to malloc. There are a lot of situations where such offscreen 'drawables' would come very handy, starting from little animated cursors over backing drawables for the scene behind transient graphics, ... Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: fastest output
someone told me (translation follows): "Ich rendere in einen Puffer alloziert via malloc. Am Ende schreibe ich den Inhalt via ggiPutBox in die Grafikkarte (Video-RAM). Im neuen Design verwende ich statt nen eigenen Puffer ein memory-visual, dessen Inhalt via ggiCrossBlit auf ein default-visual kopiert wird. => Speed up um den Faktor 10." Translation: "I render into a buffer allocated with malloc. at the end i write its content with a ggiPutBox to the graphics card (video-ram). in my new design i use an a memory-visual instead of the own buffer and do a ggiCrossBlit to a default-visual => Speed up by factor 10." i cannot believe this. i really do not understand why this should be true. i thought if i cannot get directbuffer the fastest way is use malloced buffer and do ggiPutBox. why should the CrossBlit be faster, even though it should do EXACTLY the same ? cu erik -- Name: Erik Thiele Email: [EMAIL PROTECTED]o `QQ'_ IRC: erikyyy/ __8 WWW: http://www.erikyyy.de/ ' `
