Hi!
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?)
It was more like an informal talk about meaning of life and clipping rectangle, but if you are not afraid, you are probably welcome. I preffer a mail conversations, because it's less time consuming and we don't need to get to the computer at the same time.
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?
Yes, somethink like that. It may store clipping rectangle/fb,bg color/font style/line thickness...
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.
Well, doing everything as one big library is even whorse than that.
I would personally settle here for two or three layers of libraries here.
- 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! :-)
Trully indeed. I would like to have this implemented.
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". :-)
That one often makes one wrong 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).
I see no problem in this. If you have a pointer to structure with colors they could be stored in pixel format from the start.
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).
Not sure about this. I'ts C library and I'm not "Quiche Eater". (and this is one more reason to have two layer library, one layer for "Real Programmers" consisting of API which is optimalized for shooting yourself in the leg (and building a graphics library dedicated for your purpose) and one ready to use for "Quiche Eaters".