On Sun, May 29, 2011 at 11:29 PM, Tomas Gavenciak gavento@kam.mff.cuni.cz wrote:
Hi all,
With metan, we discussed Context, blits, drawing and clipping in core.
Maybe we could arrange IRC meetings or so; it would be useful for larger infrastructure changes. (I think that Jabber allows for multi-person conversations?)
My proposal would be to remove clipping information from Context and to think about some structure for "Drawing context". This structure could also include other style information and would act as a wrapper around context and used in convenience drawing functions.
If I understand correctly, we would then have a structure that describes a bitmap and its organization, and another structure that contains drawing settings? Let's say, a Canvas/Surface/Bitmap and a Context?
The goal is to simplify the base api and modularize the library. I believe that we should allow separate use of any part of the library as much as possible - library supporting all kinds of weird devices can see many uses both with variable subset of the modules.
Well, modularization is a nice things, but please, do not overengineer that. Myriads of independent sub-libraries tend to create a dependency mess, complicate building of dependent projects, and slow things down.
Arguments to move clipping from Context to drawing are
- One use of clipping is convenience when drawing primitives. This
should be handled with drawing functions. There, clipping can save some complicated reasoning.
- Blits should not respect clipping. Blitting a superset of
clip-region is very frequent and even if needed, calculating intersection of two rectangles is very easy.
Not sure about this; for myself I would say that a graphics system that does not respect clipping with some primitives and does with some others is confusing (how to remember which is which? Does a textured triangle, which is both a blit and a primitive, respect clipping?)
- One use-case of clipping is "user" routines drawing inside windows
etc. This can be done using subcontexts (context pointing to part of memory of other context). This has also the advantage of coordinate system being always (0,0) and solves the problem when (clipped) "user" drawing routine would like to use clipping itself. Of course that every context is still "naturally" clipped by (0,0,w,h).
Now that's what I call a brilliant idea! :-)
From my own experience, I used clipping very rarely, but I see its value as a convenience mechanism. Having two variants of drawing functions - one "bare" (unclipped, without implicit style information, etc.) and an optional set of "convenience" functions (clipping, using implicit style info on BGcolor, clipping, aliasing, font, ...) would be the best of both.
I'm not sure; in accordance with Murphy's Law, the user will find out that she needs a function that uses one of the advanced features but not the rest (e.g. antialiasing but not clipping).
I would rather vote for Guido van Rossum's way of "there should be preferably one correct way to do it". :-)
It still remains a question how to implement such wrapper (structure pointing to a context? context-independent structure? something extensible or fixed? ...). I haven't given it much thought. Any ideas?
Depends on what settings the structure should contain. If it should contain any kind of color information (color, filling, background, anything) then it will always need a pointer to the real bitmap data to convert the color into appropriate format. We can, of course, do it in every function call, but that costs us some time (negligible for larger elements, horrible for PutPixel - however, PutPixel and probably HLine are special anyway - they probably need an explicit color parameter anyway because there is a chance that color will be changed wildly often, and writing it into the context every time would also waste time).
So, if the new Context structure contains any information that is somehow bound to the underlying bitmap, then it should be (IMO) bound to that bitmap, and rebinding should require a special function call (because it needs recalculations that cost time).
OTOH, it would be useful to have a Context store a color in the most precise way so that it does not become subject to accumulation of rounding errors; it makes sense to store what the user *meant* (which is not necessarily what she gets).
Best regards,
Jiri Dluhos