Hi!
My understanding is that transformations are intended for weird HW with (0,0) bottom-left and such. Mixing these "fixes" for unusual HW properties with convenience applications such as horizontal flip of coordinates of drawn line is ... not wise, has limited usefulness and will lead to confusion. (Note that there can be "real" matrix transformations for drawing rotated/shifted/... primitives)
It's not only limited to weird HW. You, most of the time, want to rotate your display on perfecly normal HW. But yes, the primary usage is intended for rotating the HW display.
What is the (intended) purpose of transformation flags on bitmaps?
My usecase is same as HW display. If you do frame buffering, the bitmaps should be drawn in desired orientation so they are just copied later to real HW.
For general usage, it may be something like "lazy rotation". But that, wasn't really settled.
Note that a general blit() that would support conversion between all pairs of pixeltypes (including palettes), bpp's (including bit-endian), axes_swap (goodbye caches if different), flip_y (easy) and flip_x (RtL vs LtR), including any combination of the last three (set all differently on src and dst ... ) is going to be ... challenging to code, optimize, debug and maintain. Most of these (almost all except same pixeltype and orientation) are going to be very expensive + hard to optimize.
I'm aware that his needs to be settled.
One of crazy ideas of mine is "lazy" rotation. The bitmaps that have these flags different from context would be rotated physically in memory on first blit after context flags has changed (which would work well for things like icons and stuff).
Or you may say that bitmap would be physicaly rotated to match context orientation. Which would save us doing code for roatated blits and works well for me.
My idea of the most common use-case would be to have a "global/common" setting (based on HW) of transformations and really transforming only when loading images or fonts.
That won't work, you need have these per display (yes there are devices with two displays even now).
The two display things are not to common, but still I don't want to add some artificial limitation for number of HW displays.
Most other libraries do only simple blit, perhaps with simple format conversion. Flips are then special functiongs. Rotation is declared to be slow and it is easy to see when is it applied.
Sure, but we are going to be better (or not?)
Love the b{l}its,