Mike Emmel wrote: > Remember what I was saying about passing in a GraphicsContext to each > graphics call.
We have sub surfaces to have multiple graphics contexts. What we could do is break out all rendering related methods (states, operations), but also the offset and clipping stuff to keep sub surfaces available by having a hard limit for the clipping rectangle in contexts you can get from it. The name of the new interface should be discussed, maybe IDirectFBGraphicsContext, but I think there might be a better one :) BTW, we should add the offset to the hardware state, e.g. SH7722 supports it. > This is the sort of thing you run into. > As we add more powerful graphics ops it just gets worse. Yeah, the interface is already quite big, while the CoreSurface is technically independent from the rendering "engine" in the graphics core. The latter uses the struct CardState (which is one of the oldest identifiers without renaming). It could become something like CoreGraphicsContext. I'm still unsure if we should continue to add all the new rendering features to the old API (and rendering core) or if there should be a completely new (set of?) interfaces that you can get for your surface. Ideally, the old and new APIs should be available at the same time on the same surface. It should be possible to run the old and a new rendering core AS it should be possible to use OpenGL (ES) and DirectFB rendering at the same time, which it is with DirectFBGL on DRI for years. > Better to just add a single graphics context object with all state > info and we can extend it.. Not only the state, but the whole rendering API including the operations needs to be there. > Then we have a single SetContext/GetContext and maybe later > postscript style push/pop. I would not put any of this logic into IDirectFBSurface which should just be a basic factory for all the rendering APIs, the old, the new, IDirectFBGL or others. What about IDirectFBGraphicsContext::Push/Pop() instead? Also, with my proposal to move the rendering functions as well we don't need a SetContext() as there's nothing in the surface that cares about the context(s). Then it should be CreateContext() instead of GetContext(). > A added advantage of a context is you can often do pipeline set up in > the set call > and you can use a context from another surface without knowing > everything about it. Using the context from another surface would not be (easily) possible in my proposal. We'd need to keep all hard clipping/offset information in the (sub) surface' interface instance data, ok, easy, it's still there :) But it would also require some method in the context to select a different surface. Should be better than a method in the surface to make the context use it as it's current surface, no MakeCurrent please :) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
