From: <jos...@ju...> - 2006-11-16 22:33:49
|
> > A way to make it cleaner and more generic would be to do as > > Jose said: render the OpenGL scene in a buffer, and render the > > buffer content in an Evas image. This should even be compatible > > with all the engines, but it may be a lot slower (I don't know, > > I never did something like that). > = > It's bound to be considerably slower.. maybe depending on > wether there's good 'render-to-texture' support. It's main worth > is as you mention that it's evas-engine agnostic, and requires > no changes to current evas. > = > There are still other options though yet to be explored.. :) > = Just to follow up on this a bit: Basically, what one wants here is a means to do one's own 'rendering' in a way that is 'fitted' to some given evas engine. The current argb32 data set/get mechanism for image objs allows one to do this in a general way that works for all engines, you can use your own routines, or a lib like cairo, or whatever.. but it requires that you render to an argb32 memory buffer. This is not very efficient compared to say using xrender to draw to a pict, or gl to draw to a gl texture or pixbuffer, etc. One way to achieve this is to have engine specific "image" objects. These would be declared in a header file much as is done for the engine "info"... possibly in these very headers themselves. These engine specific image objs would then allow one to set/get engine specific 'buffers' rather than argb32 mem buffers, eg. xrender picts, gl textures or pixbuffers, etc. It would probably not be that difficult to implement either. Any thoughts.... ? jose. |