Re: [E-devel] [RFC] SDL Engine
On Tue, 1 May 2007 02:53:52 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Simon wrote: Actually, what I really want is a GL engine that is not aware of the rendering-target, i.e. an engine that can render indifferently to the backbuffer, to the fronbuffer, to a texture, to a pbuffer... and independently of the windowing system used. Here would be the different schemes to do these things with this generic GL engine: . . . the nature of engines is that they do need to know about thier target - does it have alpha or not, what is its format, size etc. and they also assume state knowledge - i.e. what the previous and current states are as evas itself works on that principle. as jose states below - you want a render to texture gl engine (fbo). otherwise very similar to the gl_x11 enigne but target is a texture. it can share all the same core as the gl_x11 as they use gl_common. i actually would like to move the normal gl engine to render to fbo's instead of the gl backbuffer then draw these dfbo textures directly to the frontbuffer (screen) thus avoiding any need for a backbuffer at all. this will make the gl enigne work much more closely to the software engines and begin to make it a possibility for things that it currently is very bad at. (doing menus, window frames etc. with a gl engine is pointless. it is only really good at big windows with no shape etc.) I'm not certain wether or not you'll be able to do this, in that kind of generality, with respect to the windowing system. However, starting with OpenGL 1.5 there is available the framebuffer object extension which seems to allow for much of this. Here's a link to the spec: http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt Maybe you could use this approach to construct a fairly generic gl engine, and presumably support fast 'render-to-texture' functionality. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
Here, the void *engine_data holds any engine specific stuff, eg. for the xrender based engines this would be similar to the current XRImage structure (minus certain things). actually - this is a problem. you need to be able to have MULTIPLE engine share the same cached image - you need multiple engine_data's - thus why i wrapped the other way around. you need to support a software_x11, xrender_x11, gl_x11 et. engine all at once (currently It allows exactly for that. The underlying loaded, shared argb32 image is the RGBA_Image they all have a pointer to, and that is indexed in a 'common' hash. Something like the 'Evas_Image' struct I mentioned works like a generic 'wrapper', but it wraps both the RGBA_Image structure and any engine-specific added parts. It's indexed in a 'higher' cache system, specific to the engine type. The issue is then one of suitable ref-counting in both the engine cache and the common hash. In any case, this would be one way - as far as basic image caching goes. More complex caching stuff, as you mention you'd like, is something more involved and possibly more flexible in how it could be realized. if we are going to revisit caching significantly - i'd really like to look at a shared cache - ewl and etk would love it as right now each process needs to load its own fonts, images etc. and so N processes loading the same data do it N times. Agreed - in principle. But as I mentioned back when we first started mumbling about this - when you started talking multi-process shared caching... you lost me. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Mon, 30 Apr 2007 12:34:25 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Wed, 25 Apr 2007 01:17:56 +0200 Simon TRENY [EMAIL PROTECTED]
babbled:
On Tue, 24 Apr 2007 14:41:22 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY
[EMAIL PROTECTED] babbled:
On Fri, 6 Apr 2007 15:21:52 +0200,
Cedric BAIL [EMAIL PROTECTED] wrote :
I did visit the sdl website, and there seems to be
mention of using OpenGL with SDL... Is it possible to
maybe also have a gl_sdl version of the engine.. ie. one
which would presumably use some gl rendering?
I did think about that also, but I must have some priority. So
first I want to have an Ecore with all others EFL running
cleany with the software_sdl. So it's definitively possible
in my opinion, but not really on top of my TODO list :)
I have some experience with SDL + OpenGL and there is nothing
different between using OpenGL with SDL and using OpenGL with an
X11 window (OpenGL-wise). The only differences are the calls
that depends on the windowing system: the creation of the GL
context and the swapping of the front/back buffers. But I don't
think it's worth it to create an Evas engine for OpenGL+SDL. It
will be exactly the same as the GL-X11 engine (i.e just a
wrapper of the GL-common engine).
agreed. in fact the sdl engine is strange. it allocates sdl
surfaces for images
- but really doesnt do anything more than the software engine.
there is not any good reason for this, and really the sdl engine
shouldnt need to be any more than just an sdl wrapper handling
the windowing system interfacing and display of ARGB32 data to
the screen - the rest can be the software engine as-is.
Actually, I don't think there should be a GL-X11 engine in Evas
at all. Just the GL-common engine should be enough. Then all
the code to create the GL-context and to swap the buffers (that
is to say, all the code that is currently in the GL-X11 engine)
should be moved to Ecore_Evas imho. This way, if we'd like to
use OpenGL+SDL or OpenGL+Win32, there will be no need to create
a new Evas engine. We would just have to create the window, the
GL-context and to use it with the GL-common engine of Evas (all
of these could be done in Ecore_Evas). And it will make it
possible to use Evas in your own OpenGL app which already has
its own GL context: for example, you could use Evas for the GUI
of an OpenGL game, which could be really cool imho :)
i disagree. currently the engine does the swaps because that is
the onyl sane way to get performance with gl. in theory it should
render updates like the software engines do - render the update
regions to a pbuffer/texture then copy to the frontbffer instead
of allocating a whole backbuffer for the window. the problem is
that if you expose this, this mechanism is no longer tweakable by
the engine. the software engines dont force you to do anything
special before or after rendering to make them display, and the
gl engine shouldnt either imho.
I see what you mean, and actually, it's just a design problem.
But the thing is, because of this design issue, the GL engine is
far more limited that what it could actually do. The only thing we
would need to make it as powerful as it could be would be to change
Ecore_Evas_GL_X11 from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
but by doing this you ASSUME the mechanism for updating IS a
glxswapbuffers - what if it isn't? what if we change it to do what i
said (render to texture/pbuffer, then copy that to the frontbuffer) -
maybe it might do things differently based on the driver (some
drivers might be able to accelerate this, some may not).? the gl
engine in this regard is no less limited than the software_x11 -
EXCEPt it doesnt allow alternate drawable targets (pixmaps). what YOU
want is the ability for the gl engine to render to a texture or
pbuffer - and you get to specify that texture/pbuffer. that is what
you really want. it would then work no differently to the software
and xrender engines that can have pixmaps specified as targets (as a
pixmap and window are the same for rendering purposes here).
Actually, what I really want is a GL engine that is not aware of the
rendering-target, i.e. an engine that can render indifferently to the
backbuffer, to the fronbuffer, to a texture, to a pbuffer... and
independently of the windowing system used. Here would be the different
schemes to do these things with this generic GL engine:
Backbuffer +
Re: [E-devel] [RFC] SDL Engine
Simon wrote: Actually, what I really want is a GL engine that is not aware of the rendering-target, i.e. an engine that can render indifferently to the backbuffer, to the fronbuffer, to a texture, to a pbuffer... and independently of the windowing system used. Here would be the different schemes to do these things with this generic GL engine: . . . I'm not certain wether or not you'll be able to do this, in that kind of generality, with respect to the windowing system. However, starting with OpenGL 1.5 there is available the framebuffer object extension which seems to allow for much of this. Here's a link to the spec: http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt Maybe you could use this approach to construct a fairly generic gl engine, and presumably support fast 'render-to-texture' functionality. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 25 Apr 2007 01:17:56 +0200 Simon TRENY [EMAIL PROTECTED] babbled:
On Tue, 24 Apr 2007 14:41:22 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY [EMAIL PROTECTED]
babbled:
On Fri, 6 Apr 2007 15:21:52 +0200,
Cedric BAIL [EMAIL PROTECTED] wrote :
I did visit the sdl website, and there seems to be
mention of using OpenGL with SDL... Is it possible to maybe
also have a gl_sdl version of the engine.. ie. one which
would presumably use some gl rendering?
I did think about that also, but I must have some priority. So
first I want to have an Ecore with all others EFL running cleany
with the software_sdl. So it's definitively possible in my
opinion, but not really on top of my TODO list :)
I have some experience with SDL + OpenGL and there is nothing
different between using OpenGL with SDL and using OpenGL with an
X11 window (OpenGL-wise). The only differences are the calls that
depends on the windowing system: the creation of the GL context and
the swapping of the front/back buffers. But I don't think it's
worth it to create an Evas engine for OpenGL+SDL. It will be
exactly the same as the GL-X11 engine (i.e just a wrapper of the
GL-common engine).
agreed. in fact the sdl engine is strange. it allocates sdl surfaces
for images
- but really doesnt do anything more than the software engine. there
is not any good reason for this, and really the sdl engine shouldnt
need to be any more than just an sdl wrapper handling the windowing
system interfacing and display of ARGB32 data to the screen - the
rest can be the software engine as-is.
Actually, I don't think there should be a GL-X11 engine in Evas at
all. Just the GL-common engine should be enough. Then all the code
to create the GL-context and to swap the buffers (that is to say,
all the code that is currently in the GL-X11 engine) should be
moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL
or OpenGL+Win32, there will be no need to create a new Evas engine.
We would just have to create the window, the GL-context and to use
it with the GL-common engine of Evas (all of these could be done in
Ecore_Evas). And it will make it possible to use Evas in your own
OpenGL app which already has its own GL context: for example, you
could use Evas for the GUI of an OpenGL game, which could be really
cool imho :)
i disagree. currently the engine does the swaps because that is the
onyl sane way to get performance with gl. in theory it should render
updates like the software engines do - render the update regions to a
pbuffer/texture then copy to the frontbffer instead of allocating a
whole backbuffer for the window. the problem is that if you expose
this, this mechanism is no longer tweakable by the engine. the
software engines dont force you to do anything special before or
after rendering to make them display, and the gl engine shouldnt
either imho.
I see what you mean, and actually, it's just a design problem. But the
thing is, because of this design issue, the GL engine is far more
limited that what it could actually do. The only thing we would need to
make it as powerful as it could be would be to change Ecore_Evas_GL_X11
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
but by doing this you ASSUME the mechanism for updating IS a glxswapbuffers -
what if it isn't? what if we change it to do what i said (render to
texture/pbuffer, then copy that to the frontbuffer) - maybe it might do things
differently based on the driver (some drivers might be able to accelerate this,
some may not).? the gl engine in this regard is no less limited than the
software_x11 - EXCEPt it doesnt allow alternate drawable targets (pixmaps).
what YOU want is the ability for the gl engine to render to a texture or
pbuffer - and you get to specify that texture/pbuffer. that is what you really
want. it would then work no differently to the software and xrender engines
that can have pixmaps specified as targets (as a pixmap and window are the same
for rendering purposes here).
Indeed, the engine would no longer be self-sufficient since if you
don't swap the buffers, nothing would be drawn (actually it would still
be drawn on the backbuffer, but not on the screen), but if you see the
engine as GL object, these new steps make sense.
And I think accepting this design-problem is worth it if you look at
what it would make possible:
- Since the engine would behave as a GL-object, you could insert
one or several Evas-es in your GL programs, meaning you could use
for example, Evas in a 3D game
Re: [E-devel] [RFC] SDL Engine
On Wed, 25 Apr 2007 04:19:06 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
babbled:
No it won't work to use his caching code, as is, for some
of the other engines. But it can be made to work. One needs to
Just to follow up on this a bit..
Again, one could make it work (though it would require a bit
of work, some re-structuring of current stuff, etc), but the real
question here is wether this would be desirable to have or not.
One thing this would allow is for 'localized' image caches,
eg. it would allow per-evas canvas caches if desired (and indeed
his current sdl engine implementation has that), or per-'engine'
(which is better, as far as memory use is concerned), etc.
It would also 'simplify' the caching code a bit as it would
have a generalized form, and indeed it also depends on a
generalized image structure.
However, in the interest of expediting a software_sdl
engine, I'd suggest that maybe it would be better if that part
of it were left for another time, when such an idea can be looked
at in more detail. :)
agreed. a generic caching mechanism beyond the basic one behind
the common argb32 code needs more discussion. as i have mentioned
i see the need to make a layer better than just the caches so far
discussed. tile-based caches, tile-based retrieval and storage of
data so we can cache pre-scaled data, even dynamically page image
data from files as needed if you have massive images for example
etc.
Yeah, you've mentioned this to me before.. It's a good idea,
but it would take things quite a bit further than what's needed
right now. We've also talked about a 'generic' cache mechanism
before.. one that could be useful as an ecore lib say (and recall
that such a mechanism required one to give 'free', 'copy', and
other functions - very similar to what cedric proposed). But again,
that is going further afield than is needed right now.
actually now you mention it - i think we really do need a much better generic
SHARED caching lib. i have mulled over this before, but we need a way for
multiple PROCESSES to share a cache - in ram. i.e. shm segments (or mmap shared
files). so you'd need either a cache handler daemon that everyone ipc's to or a
way of having a meritocracy with the cache - but you need to lock, unlock,
modify, dirty etc. to date i actually know of no such implementation of such a
system anywhere for linux/unix etc. - a userspace generic higher level data
cache.
As far as evas image caching goes, one doesn't really need
a mechanism exactly like what cedric had, but some work there would
be good for several reasons.
First, and I think this is initially what prompted him to
attempt to rewrite things, it would be useful to have things more
'generic' in form - in order to reduce code duplication, to make
it easier to deal with engine specific image caching issues, and
things of that sort.
sure. agreed. evas's internals probably need a bit of a going-over.
For me though, this is intertwined with another basic aspect
that's needed in order to extend evas' current capabilities - namely,
we need a kind of 'engine level' object system.. preferably, one
that allows for easily 'falling back' on software routines if needed.
indeed. it has some of that for now - but not all of it.
Now, there are many ways one could do that, eg. one could
use something like what you have in e17, or in ewl or etk...
For me it was simpler to use a version of the current canvas-level
object design.
When it comes to image objects though, we also need a generic
image structure to hold data and whatever engie specific stuff.. and
to make things easier let's say we want to build these on-top-of
the current RGBA_Image structure.
Let's call these structures Engine_Image, and let's take
it to be of a form like:
struct Engine_Image
{
RGBA_Image *im;
void *engine_data;
char *cache_key;
intflags;
intrefs;
};
Here, the void *engine_data holds any engine specific
stuff, eg. for the xrender based engines this would be similar to
the current XRImage structure (minus certain things).
actually - this is a problem. you need to be able to have MULTIPLE engine share
the same cached image - you need multiple engine_data's - thus why i wrapped
the other way around. you need to support a software_x11, xrender_x11, gl_x11
et. engine all at once (currently this is broken for fonts actually as they
work in this way above).
Ok, these are our engine images which are to be loaded/
cached/etc. How do we rewrite the current caching mechnism around
these?
First, one needs a cache for each engine. This structure
can be whatever, but let's take it like the current active/inactive/
dirty system (I'm not sure the 'dirty' hash is really worth having),
which will cache such engine_image
Re: [E-devel] [RFC] SDL Engine
On Tue, 24 Apr 2007 17:33:11 -0500,
Nathan Ingersoll [EMAIL PROTECTED] wrote :
On 4/24/07, Simon TRENY [EMAIL PROTECTED] wrote:
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Is there any reason that this could not be controlled simply by the
engine info passed at setup time?
If the info contains a GL-context, use the passed context and don't
call swap_buffers, otherwise use the current behavior. Seems like you
would get the best of both worlds and the usual case would still be
just as simple as it is now.
Actually, the GL-context is almost only used to swap the buffers, so
passing the context to the engine if the engine doesn't call the
swap_buffers() functions is not really coherent I think.
And since there is no generic GL-context type (each windowing system
implements its own type for the GL-context: GLXContext for GLX, HGLRC
for Windows...), we still couldn't have a generic GL-engine (we would
still need one GL-engine per windowing system).
Simon
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
Simon TRENY wrote:
On Tue, 24 Apr 2007 17:33:11 -0500,
Nathan Ingersoll [EMAIL PROTECTED] wrote :
On 4/24/07, Simon TRENY [EMAIL PROTECTED] wrote:
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Is there any reason that this could not be controlled simply by the
engine info passed at setup time?
If the info contains a GL-context, use the passed context and don't
call swap_buffers, otherwise use the current behavior. Seems like you
would get the best of both worlds and the usual case would still be
just as simple as it is now.
Actually, the GL-context is almost only used to swap the buffers, so
passing the context to the engine if the engine doesn't call the
swap_buffers() functions is not really coherent I think.
And since there is no generic GL-context type (each windowing system
implements its own type for the GL-context: GLXContext for GLX, HGLRC
for Windows...), we still couldn't have a generic GL-engine (we would
still need one GL-engine per windowing system).
Implement swap_buffers as a callback?
Sebastian
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 25 Apr 2007 17:19:25 +0200,
Sebastian Dransfeld [EMAIL PROTECTED] wrote :
Simon TRENY wrote:
On Tue, 24 Apr 2007 17:33:11 -0500,
Nathan Ingersoll [EMAIL PROTECTED] wrote :
On 4/24/07, Simon TRENY [EMAIL PROTECTED] wrote:
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Is there any reason that this could not be controlled simply by the
engine info passed at setup time?
If the info contains a GL-context, use the passed context and don't
call swap_buffers, otherwise use the current behavior. Seems like
you would get the best of both worlds and the usual case would
still be just as simple as it is now.
Actually, the GL-context is almost only used to swap the buffers, so
passing the context to the engine if the engine doesn't call the
swap_buffers() functions is not really coherent I think.
And since there is no generic GL-context type (each windowing system
implements its own type for the GL-context: GLXContext for GLX,
HGLRC for Windows...), we still couldn't have a generic GL-engine
(we would still need one GL-engine per windowing system).
Implement swap_buffers as a callback?
It would indeed make the engine generic but then, if the engine swaps
the buffers by itself, the Evas couldn't be integrated in an OpenGL
application: here is how we could embed an Evas in an OpenGL app, if the
engine wasn't swapping the buffers:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
3. Creation of the GL-engine
3. While (1)
{
game-scene-render();
evas-engine-render();
game-overlay-render();
swap_buffers(GL-context);
}
Now, if the engine swaps the buffers at the end of the rendering
process (which is currently the case), the overlay can't be rendered
anymore (or you'll have to put the overlay-render() call in the
swap_buffers() callback, but it's kind of tricky imho)
Simon
Sebastian
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
Cedric's sdl engine email/patch has been hijacked into
a bitter battle over evas and opengl :)
Simon wrote:
It would indeed make the engine generic but then, if the engine
swaps the buffers by itself, the Evas couldn't be integrated in
an OpenGL application: here is how we could embed an Evas in an
OpenGL app, if the engine wasn't swapping the buffers:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
3. Creation of the GL-engine
3. While (1)
{
game-scene-render();
evas-engine-render();
game-overlay-render();
swap_buffers(GL-context);
}
Now, if the engine swaps the buffers at the end of the rendering
process (which is currently the case), the overlay can't be rendered
anymore (or you'll have to put the overlay-render() call in the
swap_buffers() callback, but it's kind of tricky imho)
Ok, this assumes that the game-render() itself is rendering
to the gl front/back buffer and that it too doesn't flush things.
But if that's the case, then why can't the evas gl engine in question
be rendering to a pbuffer or texture say, and then draw that to the
main render buffer (eg. as a textured quad), and then flush things?
No matter how much you want to put evas canvases into a
gl based rendering context, you are also going to want to do the
opposite - use gl rendering in an evas gl canvas.
The cleanest way to do these kinds of things, wether it's
gl based or xrender based or cairo based or your-software-routines
or via some 3D-game-engine (or even, egods, a raytracer!), is to
have evas engine specific buffers to draw to.
This is why the software engines are so powerful/versatile,
it provides a full circle - you can draw to a display target via
the software engines, and you can draw to a software buffer target,
and you can set such a buffer as 'data' for image objects.
This kind of completeness would be very desirable as well,
at least withing the context of engines driven by a given rendering
backend - software, xrender, gl, cairo, ...
jose.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 25 Apr 2007 18:56:25 GMT,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote :
Cedric's sdl engine email/patch has been hijacked into
a bitter battle over evas and opengl :)
Simon wrote:
It would indeed make the engine generic but then, if the engine
swaps the buffers by itself, the Evas couldn't be integrated in
an OpenGL application: here is how we could embed an Evas in an
OpenGL app, if the engine wasn't swapping the buffers:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
3. Creation of the GL-engine
3. While (1)
{
game-scene-render();
evas-engine-render();
game-overlay-render();
swap_buffers(GL-context);
}
Now, if the engine swaps the buffers at the end of the rendering
process (which is currently the case), the overlay can't be rendered
anymore (or you'll have to put the overlay-render() call in the
swap_buffers() callback, but it's kind of tricky imho)
Ok, this assumes that the game-render() itself is rendering
to the gl front/back buffer and that it too doesn't flush things.
But if that's the case, then why can't the evas gl engine in question
be rendering to a pbuffer or texture say, and then draw that to the
main render buffer (eg. as a textured quad), and then flush things?
Indeed, it assumes that game-scene-render(), evas-engine-render()
and evas-overlay-render() doesn't manipulate directly the GL
context (for swapping or for changing the active GL-context, for
example), but I see no reason why they would need to do that.
They should behave as independant gl objects: they should only use
OpenGL functions, and they should keep the current GL state unchanged
(this could be done easily with glPop/PushAttribs()). This is the
only way I know to do modular OpenGL programming.
About your second point, The gl-engine can render to a texture or a
pbuffer, there is no problem with this, as long as it doesn't swap the
buffers. But as raster said, it is not possible if we want to get good
performances with OpenGL, rendering to a texture is slow as hell
(don't know muck about pbuffers). And actually, it doesn't solve the
current problem at all (buffers will still have to be swapped somewhere)
No matter how much you want to put evas canvases into a
gl based rendering context, you are also going to want to do the
opposite - use gl rendering in an evas gl canvas.
Yes indeed, and this is possible with the above scheme: you
can do your gl-rendering in the game-overlay-render() function, all
the GL primitives that will be drawn in this function will be drawn
over the Evas GL canvas (you may just need to clear the Z-buffer)
The cleanest way to do these kinds of things, wether it's
gl based or xrender based or cairo based or your-software-routines
or via some 3D-game-engine (or even, egods, a raytracer!), is to
have evas engine specific buffers to draw to.
This is why the software engines are so powerful/versatile,
it provides a full circle - you can draw to a display target via
the software engines, and you can draw to a software buffer target,
and you can set such a buffer as 'data' for image objects.
This kind of completeness would be very desirable as well,
at least withing the context of engines driven by a given rendering
backend - software, xrender, gl, cairo, ...
Agreed :)
Simon
jose.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
About your second point, The gl-engine can render to a texture or a pbuffer, there is no problem with this, as long as it doesn't swap the buffers. But as raster said, it is not possible if we want to get good performances with OpenGL, rendering to a texture is slow as hell (don't know muck about pbuffers). And actually, it doesn't solve the current problem at all (buffers will still have to be swapped somewhere) I don't think 'rendering to a texture', as evas would do it, would involve swapping the front/back buffers. As to the performance issue.. This seems to depend on exactly the kind of support that the gl version/drivers have for that. It can be done with bare-bones gl using glCopyTexImage, or with various kinds of later support for 'rtt' functionality -- and as far as I've been able to quickly gather, anything that supports the gl shading language (now used in evas for yuv conversion), will support fast rtt methods, even the basic glCopyTexImage method is 'supposedly' quite fast. I don't know Simon.. want you want is certainly 'seductive' in its own way - it does have a lot of good aspects -- but I wonder if it's maybe just more gl-convenient than really necessary. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
I wrote: I don't know Simon.. want you want is certainly 'seductive' in its own way - it does have a lot of good aspects -- but I wonder if it's maybe just more gl-convenient than really necessary. On the other hand While I think that engine specific buffers, both as render targets and image object input 'data', are essential, I'm also starting to come around to Simon's view as well. As raster mentioned, a gl-x11 engine shouldn't have to do anything special to display the results.. But, it doesn't mean that it couldn't be *asked* to hold off on that. So, maybe adding a flag to the engine info, whose default setting would be to have the evas_render call display the results (as it best sees fit to do things) as it now does.. but when set otherwise would be forced to render to the gl back buffer and not flush things? jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Fri, 6 Apr 2007 15:21:52 +0200, Cedric BAIL [EMAIL PROTECTED] wrote : I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) I have some experience with SDL + OpenGL and there is nothing different between using OpenGL with SDL and using OpenGL with an X11 window (OpenGL-wise). The only differences are the calls that depends on the windowing system: the creation of the GL context and the swapping of the front/back buffers. But I don't think it's worth it to create an Evas engine for OpenGL+SDL. It will be exactly the same as the GL-X11 engine (i.e just a wrapper of the GL-common engine). agreed. in fact the sdl engine is strange. it allocates sdl surfaces for images - but really doesnt do anything more than the software engine. there is not any good reason for this, and really the sdl engine shouldnt need to be any more than just an sdl wrapper handling the windowing system interfacing and display of ARGB32 data to the screen - the rest can be the software engine as-is. Actually, I don't think there should be a GL-X11 engine in Evas at all. Just the GL-common engine should be enough. Then all the code to create the GL-context and to swap the buffers (that is to say, all the code that is currently in the GL-X11 engine) should be moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL or OpenGL+Win32, there will be no need to create a new Evas engine. We would just have to create the window, the GL-context and to use it with the GL-common engine of Evas (all of these could be done in Ecore_Evas). And it will make it possible to use Evas in your own OpenGL app which already has its own GL context: for example, you could use Evas for the GUI of an OpenGL game, which could be really cool imho :) i disagree. currently the engine does the swaps because that is the onyl sane way to get performance with gl. in theory it should render updates like the software engines do - render the update regions to a pbuffer/texture then copy to the frontbffer instead of allocating a whole backbuffer for the window. the problem is that if you expose this, this mechanism is no longer tweakable by the engine. the software engines dont force you to do anything special before or after rendering to make them display, and the gl engine shouldnt either imho. I've already discussed this with raster and he told me the only reason to bind the GL-Context with the Evas engine is because the context is stateful and if the context were to be shared between the Evas-engine and the application code, the application could change/corrupt the context's state and it could break the Evas engine. That's a good point, but actually, there is a way to save/restore the current state of a GL-context with glPushAttrib(GL_ALL_ATTRIB_BITS)/glPopAttrib(GL_ALL_ATTRIB_BITS). It saves the current viewport, the current matrices, and all the current states. I just don't know if it is efficient and if it's available on all the GL cards. and the above too - now ive been thinking about it :) Raster, what do you think about creating a generic GL-engine for Evas (with the glPushAttrib()/glPopAttrib() thing), and to move the existing code of the GL-X11 engine (creation of the context and buffer-swapping) to Ecore_Evas_GL_X11? If this is ok, I'm willing to do it if you want. well really glpushattrib/pop should get used anyway. it would really save the gl engine needing to keep its own state shadow. as above - this introduces problems. Regards, Simon TRENY MoOm Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
Re: [E-devel] [RFC] SDL Engine
On Sat, 7 Apr 2007 11:20:24 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: ok- started reviewing... and i'll basically cover as much as i had time to review here. 1. shared evas image cache - good idea, BUT... has problems. ... ... ... No it won't work to use his caching code, as is, for some of the other engines. But it can be made to work. One needs to rewrite each engine specific caching code around the interfaces, and he'd need to completely redo the way engine specific image stuff (surfaces and other things) is organized, and put it in the RGBA_Image structure as 'engine_surface' or 'engine_data' pointers. :) I did something like this -- I just didn't abstract it into a single caching mechanism with 'virtual' interfaces (which are engine dependent), just kept per-engine caching code. i can see where a generic cache engine is going, but i dont buy that it is that useful in the state the patches have it. it cant, as you say jose, handle caches per engine properly as it cannot account for engine specific properties. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 11 Apr 2007 00:11:40 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: can you be specific as to what is making things complex? Carsten wrote: ... what your cache doesn't handle is if you have 2 or 3 or 4 different engines when 2 of them are NOT software engines and both want DIFFERENT private engine data (a pixmap, render picture, texture etc.). they share the RGBA_Image but they are not able to share the private engine data for the image - you need to keep both bits of private enigne data - that is what each engine's wrapping basically does. secondly for some engines there may need to be MULTIPLE private copies - different visuals, colormaps etc. for example. different screens etc. this here is actually a current bug in the RGBA_Font stuff - the way i did the engine specific glyph painting callbacks means only 1 engine can place private data there. i need to fix this - but it would be bad to let the same issue creep in for something bigger like images :) this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. Yeah. Except that the 'sharing' of the image cache across engines of different 'types', while desirable from certain points of view (and it's initially the way I thought things should work), is now becoming a source of complexity and 'issues' for me with other things. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Tue, 24 Apr 2007 14:41:22 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY [EMAIL PROTECTED]
babbled:
On Fri, 6 Apr 2007 15:21:52 +0200,
Cedric BAIL [EMAIL PROTECTED] wrote :
I did visit the sdl website, and there seems to be
mention of using OpenGL with SDL... Is it possible to maybe
also have a gl_sdl version of the engine.. ie. one which
would presumably use some gl rendering?
I did think about that also, but I must have some priority. So
first I want to have an Ecore with all others EFL running cleany
with the software_sdl. So it's definitively possible in my
opinion, but not really on top of my TODO list :)
I have some experience with SDL + OpenGL and there is nothing
different between using OpenGL with SDL and using OpenGL with an
X11 window (OpenGL-wise). The only differences are the calls that
depends on the windowing system: the creation of the GL context and
the swapping of the front/back buffers. But I don't think it's
worth it to create an Evas engine for OpenGL+SDL. It will be
exactly the same as the GL-X11 engine (i.e just a wrapper of the
GL-common engine).
agreed. in fact the sdl engine is strange. it allocates sdl surfaces
for images
- but really doesnt do anything more than the software engine. there
is not any good reason for this, and really the sdl engine shouldnt
need to be any more than just an sdl wrapper handling the windowing
system interfacing and display of ARGB32 data to the screen - the
rest can be the software engine as-is.
Actually, I don't think there should be a GL-X11 engine in Evas at
all. Just the GL-common engine should be enough. Then all the code
to create the GL-context and to swap the buffers (that is to say,
all the code that is currently in the GL-X11 engine) should be
moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL
or OpenGL+Win32, there will be no need to create a new Evas engine.
We would just have to create the window, the GL-context and to use
it with the GL-common engine of Evas (all of these could be done in
Ecore_Evas). And it will make it possible to use Evas in your own
OpenGL app which already has its own GL context: for example, you
could use Evas for the GUI of an OpenGL game, which could be really
cool imho :)
i disagree. currently the engine does the swaps because that is the
onyl sane way to get performance with gl. in theory it should render
updates like the software engines do - render the update regions to a
pbuffer/texture then copy to the frontbffer instead of allocating a
whole backbuffer for the window. the problem is that if you expose
this, this mechanism is no longer tweakable by the engine. the
software engines dont force you to do anything special before or
after rendering to make them display, and the gl engine shouldnt
either imho.
I see what you mean, and actually, it's just a design problem. But the
thing is, because of this design issue, the GL engine is far more
limited that what it could actually do. The only thing we would need to
make it as powerful as it could be would be to change Ecore_Evas_GL_X11
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Indeed, the engine would no longer be self-sufficient since if you
don't swap the buffers, nothing would be drawn (actually it would still
be drawn on the backbuffer, but not on the screen), but if you see the
engine as GL object, these new steps make sense.
And I think accepting this design-problem is worth it if you look at
what it would make possible:
- Since the engine would behave as a GL-object, you could insert
one or several Evas-es in your GL programs, meaning you could use
for example, Evas in a 3D game to render the HUD, or in a 3D modeler
to draw the the GUI and *more important*, I could use Evas in
Egloo... which could be really cool, from a totally selfish point of
view :)
- We would also be able to draw GL primitives over an Evas (as long as
it uses the GL-engine), which was the subject of a thread on the
Dev-ML some months ago.
- The GL engine would be totally portable and independent from the
windowing system used, so we could use it with Windows, SDL, XCB,
XLib without changing one line of code. Otherwise, we would need as
many Evas enginges as there are windowing systems that we want to
support.
So, can I just ask you to reconsider this? :)
Simon TRENY MoOm
I've already discussed this with raster and he told me the only
reason to bind the GL-Context with the Evas engine is because the
context is stateful and if the context were to be shared between
the Evas-engine and the application
Re: [E-devel] [RFC] SDL Engine
On 4/24/07, Simon TRENY [EMAIL PROTECTED] wrote:
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Is there any reason that this could not be controlled simply by the
engine info passed at setup time?
If the info contains a GL-context, use the passed context and don't
call swap_buffers, otherwise use the current behavior. Seems like you
would get the best of both worlds and the usual case would still be
just as simple as it is now.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Tue, 10 Apr 2007 10:23:06 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: On Saturday 07 April 2007 11:21:22 Carsten Haitzler wrote: On Wed, 21 Mar 2007 16:58:15 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: ok- started reviewing... and i'll basically cover as much as i had time to review here. 1. shared evas image cache - good idea, BUT... has problems. it's no different to what engines do, but in reverse. engines just wrap images up in their own objects and use the common code's stuff.l you only inverted the logic - it doesn't buy anything really. what your cache doesn't handle is if you have 2 or 3 or 4 different engines when 2 of them are NOT software engines and both want DIFFERENT private engine data (a pixmap, render picture, texture etc.). they share the RGBA_Image but they are not able to share the private engine data for the image - you need to keep both bits of private enigne data - that is what each engine's wrapping basically does. secondly for some engines there may need to be MULTIPLE private copies - different visuals, colormaps etc. for example. different screens etc. this here is actually a current bug in the RGBA_Font stuff - the way i did the engine specific glyph painting callbacks means only 1 engine can place private data there. i need to fix this - but it would be bad to let the same issue creep in for something bigger like images :) this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. When I did take a look at others engines, I missed such idea. So I didn't take them into account for the cache. I will need to think how I could solve that, but I would like to try to solve this on a real case. Do you have an engine that need more than one private data ? (One that could be a good start to see, understand and fix this problem) also you were changing evas_common_load_image_from_file() to use extension to choose module - several big problems. 1. it's case sensitive. file.JPG will not pick the right loader first off Hum, that must be a bug, I used strcasecmp to handle this case. i swear i saw strcmp - maybe i didn't read carefully enough - but the other things still do apply. 2. also file.jpeg will also go the slow route. I don't see why. It must put jpeg in loader and then act exactly like the previous code. sorry this was the other way around. .jpg files will always be loaded by the slow route. it uses the extension as the loader name. not a bad guess but it fails for several common formats - it then has to try EVERY module to see if it will work. the problem is multiple extensions can map to the same loader. if we drop case sensitivity: .tif, .tiff - tiff .jpg, .jpeg, .jfif - jpeg .eet, .edj, .eap - eet .svg, .svgz - svg point is that you need a better mapping. right now there is a code that literally takes an educated guess based on extension as to which loader might be the best to try first. then it goes the long way if this fails. the only way to remove this code is have a way for a loader to advertise what extensions it handles - then you need to load the loader module and look at an array of strings or a config file or something - but removing this code isn't that good an idea. 3. even worse for .edj files! it will never pick the fast-path. Well, that sound really strange to me. As the edj extention is in the loaders array, I don't understand why it will never pick the fast-path. I mixed two changes in this patch. Splitting the function doing the loading from the one taking care of the cache and replacing the list of if with an easy to read array of string. I don't see what could have go wrong here. I will take another look at this function. wait - i may have missed that. damnit. maybe i was on crack that day. grrr. ok - went back to patch - ignore the above. yes. you have an array. it makes sense. sorry - i misread it. this is fine. but the rest of the generic cache mechanism still is not really up to what i think is a good idea. right now all it does it simply invert caching from within an engine object to outside of it. it doesn't allow to cache an engine object based on parameters like visual, colormap, display, scree, root window, and other device-dependant parameters. in that way it is really no more useful than the already done transparently for you cache in the common core. Thanks for feedback, Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash
Re: [E-devel] [RFC] SDL Engine
Cedric wrote: this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. When I did take a look at others engines, I missed such idea. So I didn't take them into account for the cache. I will need to think how I could solve that, but I would like to try to solve this on a real case. Do you have an engine that need more than one private data ? (One that could be a good start to see, understand and fix this problem) The xrender based engines. The loaded data is kept in 'pictures', which are resources that depend on other X stuff. That part would be easy to fix in what you have: add a function prototype to generate the 'cache_key' from given input (file, key, load_opts, void *engine_data). But the 'problem' goes deeper than that. Right now the argb data itself (ie. the result of loading things given only the file/key/load_opts combo) may be shared by several cached engine images, ie. images which have the same file/key/load_opts but could have different 'displays' say, and this is the real source of the 'problem'. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wednesday 11 April 2007 09:41:22 [EMAIL PROTECTED] wrote: Cedric wrote: this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. When I did take a look at others engines, I missed such idea. So I didn't take them into account for the cache. I will need to think how I could solve that, but I would like to try to solve this on a real case. Do you have an engine that need more than one private data ? (One that could be a good start to see, understand and fix this problem) The xrender based engines. The loaded data is kept in 'pictures', which are resources that depend on other X stuff. That part would be easy to fix in what you have: add a function prototype to generate the 'cache_key' from given input (file, key, load_opts, void *engine_data). Thanks, that should be easy. But the 'problem' goes deeper than that. Right now the argb data itself (ie. the result of loading things given only the file/key/load_opts combo) may be shared by several cached engine images, ie. images which have the same file/key/load_opts but could have different 'displays' say, and this is the real source of the 'problem'. I am not sure if I understand correctly the problem. As I currently implemented my cache mecanism, a RGBA_Image could only end in one image cache linked with one engine and one cache_key. Now what we want, is having one RGBA_Image in multiple cache linked with multiple engine, but with one cache_key. This cache_key should only be the same if all engine are really ok to share this RGBA_Image. Is it correct ? In that case, I need to provide a way to request each engine to compute the cache_key and if they all give the same answer, it's ok (I take for granted the fact that I could have multiple cache for one RGBA_Image. I know, it will need some thinking also). Or did I miss a bigger problem ? Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
But the 'problem' goes deeper than that. Right now the argb data itself (ie. the result of loading things given only the file/key/load_opts combo) may be shared by several cached engine images, ie. images which have the same file/key/load_opts but could have different 'displays' say, and this is the real source of the 'problem'. I am not sure if I understand correctly the problem. As I currently implemented my cache mecanism, a RGBA_Image could only end in one image cache linked with one engine and one cache_key. Now what we want, is having one RGBA_Image in multiple cache linked with multiple engine, but with one cache_key. This cache_key should only be the same if all engine are really ok to share this RGBA_Image. Is it correct ? In that case, I need to provide a way to request each engine to compute the cache_key and if they all give the same answer, it's ok (I take for granted the fact that I could have multiple cache for one RGBA_Image. I know, it will need some thinking also). Or did I miss a bigger problem ? E... I think if I try and explain this again I'm likely to cause more confusion. :) Take a quick look at eg. the xrender-x11 and gl image cache related stuff. Every engine 'image' needs to keep at least argb32 data that one can load/set/get from the canvas api. It also may want to keep such data in engine specific buffers of some sort (if it can composite such to the dst target surface via some means it posseses -- in your sdl engine case, you're not using any sdl provided functions for compositing, so you can't really benefit from keeping loaded data in sdl surfaces). But these engine specific buffers may require some form of differentiation, apart from the argb32 data they are made to hold. Now, for 'loading', one wants to be able to keep as few copies of the argb32 data as possible - regardless of the number of canvases, the type of engines, the means the engines are using for holding the data, etc. So, what are you going to do if you want to load file blah ONLY ONCE, but maybe use its argb32 data in many canvases, which may be using many different engines, some of which may want to hold that data in 'surfaces', which may need to be created in some particular way, dependent on engine info (even though they take the same loaded argb32 data as input - no making copies of the loaded data allowed either). ??? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Saturday 07 April 2007 11:21:22 Carsten Haitzler wrote: On Wed, 21 Mar 2007 16:58:15 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: ok- started reviewing... and i'll basically cover as much as i had time to review here. 1. shared evas image cache - good idea, BUT... has problems. it's no different to what engines do, but in reverse. engines just wrap images up in their own objects and use the common code's stuff.l you only inverted the logic - it doesn't buy anything really. what your cache doesn't handle is if you have 2 or 3 or 4 different engines when 2 of them are NOT software engines and both want DIFFERENT private engine data (a pixmap, render picture, texture etc.). they share the RGBA_Image but they are not able to share the private engine data for the image - you need to keep both bits of private enigne data - that is what each engine's wrapping basically does. secondly for some engines there may need to be MULTIPLE private copies - different visuals, colormaps etc. for example. different screens etc. this here is actually a current bug in the RGBA_Font stuff - the way i did the engine specific glyph painting callbacks means only 1 engine can place private data there. i need to fix this - but it would be bad to let the same issue creep in for something bigger like images :) this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. When I did take a look at others engines, I missed such idea. So I didn't take them into account for the cache. I will need to think how I could solve that, but I would like to try to solve this on a real case. Do you have an engine that need more than one private data ? (One that could be a good start to see, understand and fix this problem) also you were changing evas_common_load_image_from_file() to use extension to choose module - several big problems. 1. it's case sensitive. file.JPG will not pick the right loader first off Hum, that must be a bug, I used strcasecmp to handle this case. 2. also file.jpeg will also go the slow route. I don't see why. It must put jpeg in loader and then act exactly like the previous code. 3. even worse for .edj files! it will never pick the fast-path. Well, that sound really strange to me. As the edj extention is in the loaders array, I don't understand why it will never pick the fast-path. I mixed two changes in this patch. Splitting the function doing the loading from the one taking care of the cache and replacing the list of if with an easy to read array of string. I don't see what could have go wrong here. I will take another look at this function. Thanks for feedback, Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
Carsten wrote: ... what your cache doesn't handle is if you have 2 or 3 or 4 different engines when 2 of them are NOT software engines and both want DIFFERENT private engine data (a pixmap, render picture, texture etc.). they share the RGBA_Image but they are not able to share the private engine data for the image - you need to keep both bits of private enigne data - that is what each engine's wrapping basically does. secondly for some engines there may need to be MULTIPLE private copies - different visuals, colormaps etc. for example. different screens etc. this here is actually a current bug in the RGBA_Font stuff - the way i did the engine specific glyph painting callbacks means only 1 engine can place private data there. i need to fix this - but it would be bad to let the same issue creep in for something bigger like images :) this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. Yeah. Except that the 'sharing' of the image cache across engines of different 'types', while desirable from certain points of view (and it's initially the way I thought things should work), is now becoming a source of complexity and 'issues' for me with other things. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
ok- started reviewing... and i'll basically cover as much as i had time to review here. 1. shared evas image cache - good idea, BUT... has problems. ... ... ... No it won't work to use his caching code, as is, for some of the other engines. But it can be made to work. One needs to Just to follow up on this a bit.. Again, one could make it work (though it would require a bit of work, some re-structuring of current stuff, etc), but the real question here is wether this would be desirable to have or not. One thing this would allow is for 'localized' image caches, eg. it would allow per-evas canvas caches if desired (and indeed his current sdl engine implementation has that), or per-'engine' (which is better, as far as memory use is concerned), etc. It would also 'simplify' the caching code a bit as it would have a generalized form, and indeed it also depends on a generalized image structure. However, in the interest of expediting a software_sdl engine, I'd suggest that maybe it would be better if that part of it were left for another time, when such an idea can be looked at in more detail. :) Cedric: It seems to me that you don't really this for your engine - you don't really need to use an sdl surface for images that are created via the canvas api.. the only time I see that you really need to hold an sdl surface in images (say in the 'extended_info' pointer as you're now doing), is for images which are obtained from the target (display) surface, and such images don't need to use any cache aspects at all. If this is true, then you can just use the current 'generic' image cache - like the other software based engines do. Of course I could be wrong about this, it just seems that way to me from looking at the engine a bit. :) jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Fri, 6 Apr 2007 15:21:52 +0200 Cedric BAIL [EMAIL PROTECTED] wrote: Well for some crazy idea. I did notice that many little 2D game on Linux are using SDL, And some big ones. Unreal Tournament 2004 at least is written to use SDL for the Linux version. Dunno what they use for the Windows version. signature.asc Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Fri, 6 Apr 2007 15:21:52 +0200, Cedric BAIL [EMAIL PROTECTED] wrote : I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) I have some experience with SDL + OpenGL and there is nothing different between using OpenGL with SDL and using OpenGL with an X11 window (OpenGL-wise). The only differences are the calls that depends on the windowing system: the creation of the GL context and the swapping of the front/back buffers. But I don't think it's worth it to create an Evas engine for OpenGL+SDL. It will be exactly the same as the GL-X11 engine (i.e just a wrapper of the GL-common engine). Actually, I don't think there should be a GL-X11 engine in Evas at all. Just the GL-common engine should be enough. Then all the code to create the GL-context and to swap the buffers (that is to say, all the code that is currently in the GL-X11 engine) should be moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL or OpenGL+Win32, there will be no need to create a new Evas engine. We would just have to create the window, the GL-context and to use it with the GL-common engine of Evas (all of these could be done in Ecore_Evas). And it will make it possible to use Evas in your own OpenGL app which already has its own GL context: for example, you could use Evas for the GUI of an OpenGL game, which could be really cool imho :) I've already discussed this with raster and he told me the only reason to bind the GL-Context with the Evas engine is because the context is stateful and if the context were to be shared between the Evas-engine and the application code, the application could change/corrupt the context's state and it could break the Evas engine. That's a good point, but actually, there is a way to save/restore the current state of a GL-context with glPushAttrib(GL_ALL_ATTRIB_BITS)/glPopAttrib(GL_ALL_ATTRIB_BITS). It saves the current viewport, the current matrices, and all the current states. I just don't know if it is efficient and if it's available on all the GL cards. Raster, what do you think about creating a generic GL-engine for Evas (with the glPushAttrib()/glPopAttrib() thing), and to move the existing code of the GL-X11 engine (creation of the context and buffer-swapping) to Ecore_Evas_GL_X11? If this is ok, I'm willing to do it if you want. Regards, Simon TRENY MoOm Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 21 Mar 2007 16:58:15 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: ok- started reviewing... and i'll basically cover as much as i had time to review here. 1. shared evas image cache - good idea, BUT... has problems. it's no different to what engines do, but in reverse. engines just wrap images up in their own objects and use the common code's stuff.l you only inverted the logic - it doesn't buy anything really. what your cache doesn't handle is if you have 2 or 3 or 4 different engines when 2 of them are NOT software engines and both want DIFFERENT private engine data (a pixmap, render picture, texture etc.). they share the RGBA_Image but they are not able to share the private engine data for the image - you need to keep both bits of private enigne data - that is what each engine's wrapping basically does. secondly for some engines there may need to be MULTIPLE private copies - different visuals, colormaps etc. for example. different screens etc. this here is actually a current bug in the RGBA_Font stuff - the way i did the engine specific glyph painting callbacks means only 1 engine can place private data there. i need to fix this - but it would be bad to let the same issue creep in for something bigger like images :) this is why there is a specific engine copy wrapping the image - the RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine image colds a pointer to that plus engine specific data. the image is also looked up not just by filename + key, but ALSO by engine specific properties too. also you were changing evas_common_load_image_from_file() to use extension to choose module - several big problems. 1. it's case sensitive. file.JPG will not pick the right loader first off 2. also file.jpeg will also go the slow route. 3. even worse for .edj files! it will never pick the fast-path. slight problem here is that the sdl engine depends on this patch and i'm seeing some issues with it :( Hi everybody, I finally got a SDL Engine running and starting to look correct. I did split it in 3 patch. - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. I also included in this patch a new 'evas_common_load_image_module_from_file' function that just create the RGBA_Image without any cache manipulation. I also updated 'evas_common_load_image_from_file' function to use it. - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. - evas_sdl_test.diff: Add an old style evas test for SDL engine. Every test must work, if not please report bugs to me :) Now, this is not perfect and I think some more work is needed. I noticed that a lot of engine inherit their function from software generic engine, but as we don't have an Evas_Common_Render_Engine, some functions needs to be duplicated in all engines. If we have a common Render_Engine structure with Tilebuf, Tilebuf_Rect, cur_rect and a void* extended_render_engine for specific render engine information, this would not be necessary. If everybody agree, I will just work on that. During the time I developed the cache mechanism for the SDL engine, I looked in all engines to understand how they did this task. And some engine are first class citizen with complete/complex cache mechanism, others are really not that much lucky :) I would like to make them use evas_cache_image progressively. When all of them will use evas_cache_image, it should be possible to make the cache part of the common render engine and remove more code from the engine. So maintaining and writing good engine should be more easy. Well that's my objective here, so if people have better idea or any opinion on this I would really like to ear them (here or on irc, I am cedric on #e, don't hesitate to highlight). Cedric -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
Re: [E-devel] [RFC] SDL Engine
Cedric wrote: I finally got a SDL Engine running and starting to look correct. I did split it in 3 patch. - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. raster will be the one to bless or damn this :) but I took a quick look at it and thought I'd give you some of my impressions. I like the cache stuff. I actually had to do something similar recently (though I didn't bother abstracting it as much as you did here). A couple of things quickly came to mind though: You're using the image struct's extended_info pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra void *engine_surface for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? There are some things I think could be cleaned up... maybe the various assert calls could be replaced by a more 'silent' means of checking for invalid inputs? Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. Ummm... I'll have to preface what follows here by saying that I know nothing about sdl, and haven't really looked at the engine too much... But from what I can gather: It seems to be what I'd call a 'generic' implementation -- ie. uses the software routines for things and puts the result argb on the dst surface. If so, I think it might then be best to call it software_sdl? Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? (for the yuv color space why not then use software conversion routines?) Or maybe I'm reading that wrong? I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? Now, this is not perfect and I think some more work is needed. It's a lot, even as is :) Sure it could be better... What can't? Anyway that's just my limited feedback for now, based on a quick look. I'm sure raster will disect and digest it all far better, when he gets a chance. :) Keep the spam coming. jose. BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Friday 06 April 2007 09:58:26 [EMAIL PROTECTED] wrote: Cedric wrote: - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. raster will be the one to bless or damn this :) but I took a quick look at it and thought I'd give you some of my impressions. Nice you take the time also. I like the cache stuff. I actually had to do something similar recently (though I didn't bother abstracting it as much as you did here). A couple of things quickly came to mind though: You're using the image struct's extended_info pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra void *engine_surface for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? I didn't see it, it would perhaps be a good idea to have this engine_surface directly as a part of the RGBA_Image (I did use extended_info, because I didn't see any use of it). There are some things I think could be cleaned up... maybe the various assert calls could be replaced by a more 'silent' means of checking for invalid inputs? I like assert when developping, they stop the apps as soon as needed. But after debugging, they must be useless and never trigerred. I could remove them completely I think. Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? It's faster, easier (one line of code :-) ), to look into a hash to find the right image to use. The LRU is only used when we need to drop some content due to cache presure. - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. Ummm... I'll have to preface what follows here by saying that I know nothing about sdl, and haven't really looked at the engine too much... But from what I can gather: It seems to be what I'd call a 'generic' implementation -- ie. uses the software routines for things and puts the result argb on the dst surface. If so, I think it might then be best to call it software_sdl? Yes, it's mainly a software_sdl. I wanted to use more SDL function, but most of them are useless due to the strange way they handle the alpha case. The only case that really use SDL is when doing the update of a surface with SDL_UpdateRects. Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? Mainly for SDL_UpdateRects as it could be of some use, and also because direct access to the SDL_Surface is the same as an access to the RGBA_Surface software surface. (for the yuv color space why not then use software conversion routines?) Or maybe I'm reading that wrong? I think I could use the software conversion routines, I just want to be sure that the SDL YUV function are also useless before doing it. I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) Now, this is not perfect and I think some more work is needed. It's a lot, even as is :) Sure it could be better... What can't? :) Anyway that's just my limited feedback for now, based on a quick look. I'm sure raster will disect and digest it all far better, when he gets a chance. :) Thanks, for the feedback ! Keep the spam coming. Of course ! BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. Well for some crazy idea. I did notice that many little 2D game on Linux are using SDL, but they always need to re develop their own EFL like functionnality because SDL is really limited. The drawback of the EFL is that they need a specific engine each time we want to make it run on a new device/OS. The SDL provide an easy solution to
Re: [E-devel] [RFC] SDL Engine
You're using the image struct's extended_info pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra void *engine_surface for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? I didn't see it, it would perhaps be a good idea to have this engine_surface directly as a part of the RGBA_Image (I did use extended_info, because I didn't see any use of it). Oh there's no void *engine_surface pointer right now, it's something I added to my local copy since I wanted a single 'image' structure for all engines (in fact, I had to introduce engine level 'objects' in order to have things like texturing and clipping). The 'extended_info' pointer isn't used anywhere at the moment, but it could be.. if indeed it was meant to hold additional file format related 'meta data' of some sort. Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? It's faster, easier (one line of code :-) ), to look into a hash to find the right image to use. The LRU is only used when we need to drop some content due to cache presure. Yes, but it's only faster when it *fails* to find a cached (ie. inactive) image. If it suceeds (which is the whole point of having the cache), then it could actually be slower.. because not only will you have to remove the image from the inactive hash, but also from the lru list and remove it. You also need to add images to both the hash and the list when they are to be cached, and when flushing the cache you again need to go thru both. Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? Mainly for SDL_UpdateRects as it could be of some use, and also because direct access to the SDL_Surface is the same as an access to the RGBA_Surface software surface. I'm not sure I follow you here.. Why do you need to keep an sdl surface for api created images (eg. loaded, etc), when those surfaces never seem to be used by any sdl functions (as far as a dst sdl surface is concerned)? There are cases where it could be useful to keep such, even if you're not using any sdl based compositing funcs (assuming there are such) -- you could use 'copy' ones in certain cases. Using sdl copy funcs would also be useful in things like rect drawing, with eg. rgb colors. One thing you may want to look into, assuming sdl does have some built-in compositing capabilities, is wether they can allow for using premul color data (there's plenty of time to get into that kind of thing a bit later). I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) Ahhh, good. :) I just wondered if it could be done at all. There's plenty of time to get to such an engine, and/or tweak the software based one, etc. It's a lot just to get something working in place. :) BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. Well Now that was informative, and interesting! Thanks. :) jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wednesday 21 March 2007 16:58:15 Cedric BAIL wrote:
- evas_cache_image.diff: Add a global cache for image mechanism.
I hope it could be shared with other engine and reduce their code
complexity. This cache works more like the one from FreeType, you request
image/operation from the cache, and the cache forwards it if needed to the
right callback function. This need to be carefully reviewed, even if it
seems correct. I also included in this patch a new
'evas_common_load_image_module_from_file' function that just create the
RGBA_Image without any cache manipulation. I also updated
'evas_common_load_image_from_file' function to use it.
Oops, I don't know how I didn't catch a little bug with image dirty before as
it show up when runing evas_sdl_test...
Well I also dislike warning during compilation, the second patch will remove
the one I introduced in 'evas_common_load_image_from_file'.
Cedric
diff -X exclude.cvs -Nrau e17-main/libs/evas/src/lib/cache/evas_cache_image.c e17-dev/libs/evas/src/lib/cache/evas_cache_image.c
--- e17-main/libs/evas/src/lib/cache/evas_cache_image.c 2007-03-28 21:57:26.0 +0200
+++ e17-dev/libs/evas/src/lib/cache/evas_cache_image.c 2007-03-28 19:16:39.0 +0200
@@ -219,8 +219,8 @@
RGBA_Image*
evas_cache_image_dirty(RGBA_Image* im, int x, int y, int w, int h)
{
+ RGBA_Image* im_dirty = im;
Evas_Cache_Image*cache;
- RGBA_Image* im_dirty;
char*hkey;
assert(im);
diff -X exclude.cvs -Nrau e17-main/libs/evas/src/lib/engines/common/evas_image_load.c e17-dev/libs/evas/src/lib/engines/common/evas_image_load.c
--- e17-main/libs/evas/src/lib/engines/common/evas_image_load.c 2007-03-28 21:57:26.0 +0200
+++ e17-dev/libs/evas/src/lib/engines/common/evas_image_load.c 2007-03-26 23:06:56.0 +0200
@@ -29,7 +29,7 @@
{
RGBA_Image *im;
Evas_Image_Load_Func *evas_image_load_func = NULL;
- char *loader = NULL;
+ const char *loader = NULL;
char *dot;
Evas_List*l;
Evas_Module *em;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On 3/21/07, Cedric BAIL [EMAIL PROTECTED] wrote: Hi everybody, I finally got a SDL Engine running and starting to look correct. I did split it in 3 patch. - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. I also included in this patch a new 'evas_common_load_image_module_from_file' function that just create the RGBA_Image without any cache manipulation. I also updated 'evas_common_load_image_from_file' function to use it. - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. - evas_sdl_test.diff: Add an old style evas test for SDL engine. Every test must work, if not please report bugs to me :) Great to see it happen. I'm about to write an engine to carry operations in 16bpp and had already noticed this code duplication, so this helps me a bit :-) My idea is similar to SDL_ConvertSurface(), however I plan to handle alpha transparency too... we do it with Canola/SDL and performance is incredible faster[*] than 32bpp-16bpp at every blit. My aim is to have a pure-x11 engine, fixed for 16bpp, avoiding overheads. However, with your engine at hand it should be much easier to evaluate how well it work. Do you plan to add this bit-depth support for it? [*] http://lists.libsdl.org/pipermail/sdl-libsdl.org/2001-April/016483.html Blit565to565SurfaceAlpha(): If you opt to drop quality in favor of performance, you can pack r5g6b5 inside one 32bits word and use 5bit-Alpha, doing add or multiply of 3 channels with one operation. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wednesday 21 March 2007 18:18:41 you wrote: On 3/21/07, Cedric BAIL [EMAIL PROTECTED] wrote: Hi everybody, I finally got a SDL Engine running and starting to look correct. I did split it in 3 patch. - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. I also included in this patch a new 'evas_common_load_image_module_from_file' function that just create the RGBA_Image without any cache manipulation. I also updated 'evas_common_load_image_from_file' function to use it. - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. - evas_sdl_test.diff: Add an old style evas test for SDL engine. Every test must work, if not please report bugs to me :) Great to see it happen. I'm about to write an engine to carry operations in 16bpp and had already noticed this code duplication, so this helps me a bit :-) Great to see this could help others. My idea is similar to SDL_ConvertSurface(), however I plan to handle alpha transparency too... we do it with Canola/SDL and performance is incredible faster[*] than 32bpp-16bpp at every blit. My aim is to have a pure-x11 engine, fixed for 16bpp, avoiding overheads. However, with your engine at hand it should be much easier to evaluate how well it work. Do you plan to add this bit-depth support for it? Well my TODO is quite huge at the moment, and I first want to have it integrated with ecore and emotion able to run with this engine. So I must admit that such optimization are really low priority on my list even if I like the idea, but if you have time to add this, it will be great. [*] http://lists.libsdl.org/pipermail/sdl-libsdl.org/2001-April/016483.html Blit565to565SurfaceAlpha(): If you opt to drop quality in favor of performance, you can pack r5g6b5 inside one 32bits word and use 5bit-Alpha, doing add or multiply of 3 channels with one operation. Interesting patch, I like the idea, sad I don't have all the time I need :) Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
Hi everybody, I finally got a SDL Engine running and starting to look correct. I did split it in 3 patch. Wow. That's remarkable work Cedric. :) I have a very 'naive' question for you though: What exactly is SDL, and why do people find it an interesting dsiplay target/ rendering engine... ?? jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 21 Mar 2007 21:36:08 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a very 'naive' question for you though: What exactly is SDL, and why do people find it an interesting dsiplay target/ rendering engine... ?? http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer signature.asc Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
and not only games, but a lot of softwares, like image processing,
special effects and videoconferencing (my work for now :) )
--
|| 11 | 01 | 07 ||
EPISODIO 3 LANCADO! - Luna F; Parte2
:: :: CyberEnvironment :: ::
}]| www.mdkcore.da.ru |[{
--
Na União Soviética, o e-mail escreve VOCÊ!!
~ Reversal Russa sobre Escrever e-mail
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
