[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas GL engine and several windows
On Mon, 10 Apr 2006 09:01:50 +0200 Simon TRENY <email@example.com> babbled:
> Le Sun, 9 Apr 2006 09:49:05 +0900,
> Carsten Haitzler (The Rasterman) <firstname.lastname@example.org> a _crit :
> > On Sat, 8 Apr 2006 15:19:54 +0200 Simon TRENY <email@example.com>
> > 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 :/
scaling the texture "is not an option" because of the quality loss (blurriness)
- that offends me so much... no way! :) but yes - u'd need to split it into a
mesh of textures (some grid with multiple textures properly aligned and just
overlapping so interpolation between the tiles will work right).
> > 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
the gl engine doesn't "cut out" rendering for objects completely obscured by
others. also it makes no use of stored procedures (stored geometry). this
chould be improved of course.
> 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
well - you can't do that often because you need to draw from bottom to top.
only IF the objects can be drawn at once... but that's probably not worth it.
> that we have to enable the zbuffer testing, but I guess the gain of
oh yes - i am not sure if zbuffer would help or not. it may - it could work
with full occlusion testing though. it's a toss-up if it helps or slows down.
> 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?
no - evas (the canvas level) does the immediate mode work - calling draw calls
from bottom to top. right now it's not possible. i think you may gain more
though by handling clip-outs as evas does this for the sw and xrender engines
(the gl engine just ignores the info) as this is done structurally higher up.
> > 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 firstname.lastname@example.org
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)