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

Re: [E-devel] Evas GL engine and several windows



Le Sun, 9 Apr 2006 09:49:05 +0900,
Carsten Haitzler (The Rasterman) <raster@rasterman.com> a _crit :

> On Sat, 8 Apr 2006 15:19:54 +0200 Simon TRENY <simon.treny@free.fr>
> babbled:
> 
> > Hi,
> > 
> > I'm trying to use the GL engine of evas in some applications, but it
> > seems that as soon as I create a new window, the previous windows
> > are not refreshed correctly anymore. I have to resize those windows
> > to get them refreshed.
> > 
> > Is this a problem of OpenGL or is this just because the
> > implementation of the GL engine in evas/ecore_evas is incorrect?
> > And can you also give me a list of the known problems with the GL
> > engine? For now, this is the only one I noticed (with an Nvidia
> > gpu), except another problem with the smooth scaling of images (but
> > I guess this one can be easily fixed by changing the texture
> > filters)
> 
> ok this is due to me having some bug in my gl context sharing code.
> basically i am trying to share a gl context between multiple glx
> output windows - so i don't duplicate textures etc. per window. i
> either have done something wrong - or missed a context change thing
> somewhere. that's basically the problem here.
> 
> anyway - known problems:
> 
> 1. a font with glyphs > 256x256 pixels will just break.
> 2. images that are bigger than max texture size simply won't show
> (need to build a mesh)
> 3. cards that don't support rectangular textures will end up with
> nasty scaling results when scaling "stretched" or "squashed" mostly
> in 1 dimension (mipmap issues basically when used for 2d)

I guess problems 2 and 3 can be solved either by scaling the texture to
a new correct size (easy to do but it may make the image blurry), or by
splitting the texture in smaller ones with correct size. But it may
indeed be painful to do :/

> 4. scaling down even with smooth scaling is ugly (need to use
> anisotropic filtering  if possible)
> 5. doesn't support destination alpha (easy-ish to fix)
> 6. need pbuffer support implemented for the future (we need to be
> able to render to an intermediate buffer)
> 7. if the window is fullscreen glx may choose to do page flipping not
> copy from back to front buffer. in this case evas's assumption that
> the buffer was exactly as it left it when it last rendered is wrong -
> as it actually is as it was rendered 2 frames ago, not the last frame.

I also noticed that when you have a lot of objects, the perfs can be
even worse than with the software engine. Maybe this could be improved
by, instead of drawing the objects one by one, store them in a list,
sort the list by texture, and then draw all the objects that have the
same texture in one call (using vertex arrays?). The only problem is
that we have to enable the zbuffer testing, but I guess the gain of
perf will be worth it. Is it possible actually to do that (rendering
all the objects at the end of the rendering process) with the current
engine API of evas?

Simon

> 
> that's a list off the top of my head. :)
> 
> > Regards,
> > Simon TRENY <MoOm>
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media.
> > Attend the live webcast and join the prime developer group breaking
> > into this new coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________ enlightenment-devel
> > mailing list enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> 
>