Gosh I really painted myself into a corner
-
Warning: C++ rant So I'm making an image base class for things like jpgs, pngs and svgs (those are my 3 derivations) JPGs use CMYK888 color model, SVGs use RGBA8888, and PNGs vary but often RGBA8888 The way my library works is that it supports different color models at arbitrary bit depths, but the model is part of the type signature. like
rgba_pixel<32>vscmyk_pixel<32>This creates problems for me trying to produce a generalized draw callback for images because the source format and color model can vary. Now you might think "why not abstract your pixel with a common interface?". These pixels are a binary footprint, and are the nearest available word size to the actual size of a pixel in memory, for very good reason. Also they compile to integer literals a lot of time (as long as it's a fixed color at compile time). If I start hanging a vtable off of it all that changes. One thing I could do is accept a common color format for every image. Just force it to be rgba_pixel<32> (RGBA8888) and call it good enough, but that leaves a bit of a bad taste in my mouth. Another thing I can do is templatize everything to accept a pixel type but that just kicks the can down the road, and worse, causes template poisoning/template creep. Further complicating matters is the fact that images produce their data in different ways. JPGs yield 8x8 regions until the entire space is filled. PNGs give you sold colored rectangles of various sizes (as small as 1x1) to draw. BMPs give you an entire horizontal line at a time, bottom to top, and SVGs plot one pixel at a time. I have figured out how to abstract that, but not in a way that works efficiently with every format, so I need to poke around more, especially with the SVG code to see if I can get it to produce small bitmap regions. Probably it will speed things up as well. I occasionally find myself in a position where I wished C++ was more expressive, but in this case, while I wish that, what I want I want is probably impossible. I want a common binary interface for something that is not generalized. Ain't no language feature gonna change that. :(Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Warning: C++ rant So I'm making an image base class for things like jpgs, pngs and svgs (those are my 3 derivations) JPGs use CMYK888 color model, SVGs use RGBA8888, and PNGs vary but often RGBA8888 The way my library works is that it supports different color models at arbitrary bit depths, but the model is part of the type signature. like
rgba_pixel<32>vscmyk_pixel<32>This creates problems for me trying to produce a generalized draw callback for images because the source format and color model can vary. Now you might think "why not abstract your pixel with a common interface?". These pixels are a binary footprint, and are the nearest available word size to the actual size of a pixel in memory, for very good reason. Also they compile to integer literals a lot of time (as long as it's a fixed color at compile time). If I start hanging a vtable off of it all that changes. One thing I could do is accept a common color format for every image. Just force it to be rgba_pixel<32> (RGBA8888) and call it good enough, but that leaves a bit of a bad taste in my mouth. Another thing I can do is templatize everything to accept a pixel type but that just kicks the can down the road, and worse, causes template poisoning/template creep. Further complicating matters is the fact that images produce their data in different ways. JPGs yield 8x8 regions until the entire space is filled. PNGs give you sold colored rectangles of various sizes (as small as 1x1) to draw. BMPs give you an entire horizontal line at a time, bottom to top, and SVGs plot one pixel at a time. I have figured out how to abstract that, but not in a way that works efficiently with every format, so I need to poke around more, especially with the SVG code to see if I can get it to produce small bitmap regions. Probably it will speed things up as well. I occasionally find myself in a position where I wished C++ was more expressive, but in this case, while I wish that, what I want I want is probably impossible. I want a common binary interface for something that is not generalized. Ain't no language feature gonna change that. :(Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Just throwing this out there… so the high level apis don’t show the lower type specs, but all take a generic callback pointer. The callback must match the lower type requirements? Compiler won’t be able to help here, but if your bitmaps show up incorrectly, they should catch that pretty fast in testing.
-
Just throwing this out there… so the high level apis don’t show the lower type specs, but all take a generic callback pointer. The callback must match the lower type requirements? Compiler won’t be able to help here, but if your bitmaps show up incorrectly, they should catch that pretty fast in testing.
The stack frame would be different for different signatures. I'd have to make a sig that took something very general like void* for the bitmap data - not out of the question.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Warning: C++ rant So I'm making an image base class for things like jpgs, pngs and svgs (those are my 3 derivations) JPGs use CMYK888 color model, SVGs use RGBA8888, and PNGs vary but often RGBA8888 The way my library works is that it supports different color models at arbitrary bit depths, but the model is part of the type signature. like
rgba_pixel<32>vscmyk_pixel<32>This creates problems for me trying to produce a generalized draw callback for images because the source format and color model can vary. Now you might think "why not abstract your pixel with a common interface?". These pixels are a binary footprint, and are the nearest available word size to the actual size of a pixel in memory, for very good reason. Also they compile to integer literals a lot of time (as long as it's a fixed color at compile time). If I start hanging a vtable off of it all that changes. One thing I could do is accept a common color format for every image. Just force it to be rgba_pixel<32> (RGBA8888) and call it good enough, but that leaves a bit of a bad taste in my mouth. Another thing I can do is templatize everything to accept a pixel type but that just kicks the can down the road, and worse, causes template poisoning/template creep. Further complicating matters is the fact that images produce their data in different ways. JPGs yield 8x8 regions until the entire space is filled. PNGs give you sold colored rectangles of various sizes (as small as 1x1) to draw. BMPs give you an entire horizontal line at a time, bottom to top, and SVGs plot one pixel at a time. I have figured out how to abstract that, but not in a way that works efficiently with every format, so I need to poke around more, especially with the SVG code to see if I can get it to produce small bitmap regions. Probably it will speed things up as well. I occasionally find myself in a position where I wished C++ was more expressive, but in this case, while I wish that, what I want I want is probably impossible. I want a common binary interface for something that is not generalized. Ain't no language feature gonna change that. :(Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
No doubt your work is of great consequence and significant. I the other day raised my arms in victory merely having discovered how in C++ to templatize function calls per tuple size. "I must have had lessons." - Reverend Jim Ignatowski / Christopher Lloyd
-
No doubt your work is of great consequence and significant. I the other day raised my arms in victory merely having discovered how in C++ to templatize function calls per tuple size. "I must have had lessons." - Reverend Jim Ignatowski / Christopher Lloyd
More of consequence to me than anything. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix