[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] User-control of GL-context creation and draw/read buffer s

	Rene writes:

> Speaking of OpenGL, I'd like to repeat an earlier question which
> got lost in the discussion (this mail here is mostly for the
> curious who wants a different perspective on the usual discussion
> of opengl support/interfacing in Evas):
> If I'm not mistaken, the user is the one who creates an X drawable
> which Evas uses, whereas the x11gl evas-engine will itself create
> the X context. Isn't that odd? Should it not be so that the user
> also has control over creating that X context (as well the buffers
> that x11gl renders to, e.g. a PBuffer if desired).
> ....
> ....
	That depends on what evas is primarily to be used for...
mostly it's a retained-mode canvas lib with a set of primitive
graphic types and a certain mechanism to build 'groups' of these.
Even having a more extensible set of object types would still
keep evas primarily within this realm.

	The existance of various 'engines' for a given display
target (eg. an x11 drawable) is mostly an internal matter at this
point, rather than a 'feature' for one to exploit in one's own
graphic rendering to that target.

	Should evas allow for the user to take further advantage
of a given engine for their own rendering needs? I'd say yes.
	But, wether to do this by providing an interface to render
to engine 'buffers' that evas can then use in one of its graphic
primitives (eg. say images)... or wether to do this so that the user
has nearly full control in rendering to the target... Which would
be "better"... Or how much of one or the other...???

	Note that it would be possible to have gl engines that
would render to a texture or a pixbuffer, instead of an x11
drawable, or an xrender engine that renders to a picture.. just as
there is a 'software-buffer' engine that renders to an argb32.

	The main benefit of the argb32 'universal' buffer is to
provide one convenient such for use with all engines, not to have
the most efficient mechanism for any given engine. It's simple,
convenient, and useful.. if not always the fastest way to do this
or that.

	Providing engine-specific 'buffers' would seem like the next
logical step, one just needs to work out how evas should interface
with them, as inputs and as outputs.

	Anyway.... Good work rene. :)