I hate being hung up and indecisive.
-
Hi rubber ducks! :-D My graphics library has stateless raster operations:
draw::filled_rectangle(destination,destination_rectangle,color,optional_clipping_rectangle)draw::ellipse(destination,destination_rectangle,color,optional_clipping_rectangle)etc where destination is the drawing surface, be it a bitmap, a viewport or whatever. i really want my vector operations to work that way too, but there are underlying complications. basically, you have to build out paths with multiple calls, and then you can render that. I can't decide how I want to expose the canvas - which I need to have bound to a "destination" (as above) a template class called canvas? (the destination is arbitrary, with no common base, so must use source level linking eg: templates) a class with a bunch of template methods? (actually thinking about it this won't work in this case) If I use the template class I can potentially do like this:auto canvas = draw::canvas(destination,destination_rect);at which point I could docanvas.arc(...)for example I don't like that it works so different than my raster functionality. It's stateful, but I'm not sure I can avoid that I'm not sure if I like binding it to a destination using the draw:: class (draw::canvas) And there are a bunch of details that I need to work out like Do I combine stroke and fill data in one structure, or do I require you to define strokes and fills using multiple calls? (my prior SVG stuff worked the first way, pluto works the latter way, but I can make it work the first way) I have so many questions spinning around in my head, and it's stopping me from moving forward. I still think if you're working on software correctly, this is part of the process - better to get hung up in design then to paint yourself into a corner during implementation. Still, it's frustrating.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Hi rubber ducks! :-D My graphics library has stateless raster operations:
draw::filled_rectangle(destination,destination_rectangle,color,optional_clipping_rectangle)draw::ellipse(destination,destination_rectangle,color,optional_clipping_rectangle)etc where destination is the drawing surface, be it a bitmap, a viewport or whatever. i really want my vector operations to work that way too, but there are underlying complications. basically, you have to build out paths with multiple calls, and then you can render that. I can't decide how I want to expose the canvas - which I need to have bound to a "destination" (as above) a template class called canvas? (the destination is arbitrary, with no common base, so must use source level linking eg: templates) a class with a bunch of template methods? (actually thinking about it this won't work in this case) If I use the template class I can potentially do like this:auto canvas = draw::canvas(destination,destination_rect);at which point I could docanvas.arc(...)for example I don't like that it works so different than my raster functionality. It's stateful, but I'm not sure I can avoid that I'm not sure if I like binding it to a destination using the draw:: class (draw::canvas) And there are a bunch of details that I need to work out like Do I combine stroke and fill data in one structure, or do I require you to define strokes and fills using multiple calls? (my prior SVG stuff worked the first way, pluto works the latter way, but I can make it work the first way) I have so many questions spinning around in my head, and it's stopping me from moving forward. I still think if you're working on software correctly, this is part of the process - better to get hung up in design then to paint yourself into a corner during implementation. Still, it's frustrating.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Prolly not what you fancy, but if it gives you any ideas... The way I picture vector graphics is basically an infinite 2D-canvas.On that, we
drawall the ellipses, rectangles and cats. The rectangle only comes to play when werender.Canvas canvas;
draw::ellipse(canvas, bounding_rectangle, color); // overload
draw::shape2D(canvas, shape, color);canvas.render(source_rect, raster_destination)
Personally, I would cut the mooring to
draw::and evenCanvas canvas;
canvas.ellipse(bounding_rectangle, color); // overload
canvas.shape2D(shape, color);canvas.render(source_rect, raster_destination)
"If we don't change direction, we'll end up where we're going"
-
Prolly not what you fancy, but if it gives you any ideas... The way I picture vector graphics is basically an infinite 2D-canvas.On that, we
drawall the ellipses, rectangles and cats. The rectangle only comes to play when werender.Canvas canvas;
draw::ellipse(canvas, bounding_rectangle, color); // overload
draw::shape2D(canvas, shape, color);canvas.render(source_rect, raster_destination)
Personally, I would cut the mooring to
draw::and evenCanvas canvas;
canvas.ellipse(bounding_rectangle, color); // overload
canvas.shape2D(shape, color);canvas.render(source_rect, raster_destination)
"If we don't change direction, we'll end up where we're going"
That's essentially how i envision it to work. There is no explicit render method however, due to the way it functions. The issue with the color is you don't just have one. You have potentially a stroke color and a fill color. Or you can do linear and radial gradients or textures. It gets complicated. The way it works currently in pluto, is you call series of functions (in straight C) to set the various color properties for stroke and fill, or textures or whatever. Then you render your shapes, more or less. I'm thinking of making it more like your way, except if I do the parameter list will be struct heavy due to all the options. Still not sure.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Prolly not what you fancy, but if it gives you any ideas... The way I picture vector graphics is basically an infinite 2D-canvas.On that, we
drawall the ellipses, rectangles and cats. The rectangle only comes to play when werender.Canvas canvas;
draw::ellipse(canvas, bounding_rectangle, color); // overload
draw::shape2D(canvas, shape, color);canvas.render(source_rect, raster_destination)
Personally, I would cut the mooring to
draw::and evenCanvas canvas;
canvas.ellipse(bounding_rectangle, color); // overload
canvas.shape2D(shape, color);canvas.render(source_rect, raster_destination)
"If we don't change direction, we'll end up where we're going"
Adding, the only way I could cut the binding to draw is to provide an alternative mechanism to bind to a destination and destination rectangle for the canvas. The canvas itself cannot actually render without something to render to, like a bitmap. The issue is the backing draw target can be of any sort of color model or pixel format. RGB8888, RGB565, etc. Each different model has a different type signature, so the canvas class would have to be a template, and a binding template function makes it easier to attach a canvas to a surface. draw:: is currently where people go to do all drawing operations on a draw target, so it makes at least some sense to use draw:: to bind, depending on how you look at it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Adding, the only way I could cut the binding to draw is to provide an alternative mechanism to bind to a destination and destination rectangle for the canvas. The canvas itself cannot actually render without something to render to, like a bitmap. The issue is the backing draw target can be of any sort of color model or pixel format. RGB8888, RGB565, etc. Each different model has a different type signature, so the canvas class would have to be a template, and a binding template function makes it easier to attach a canvas to a surface. draw:: is currently where people go to do all drawing operations on a draw target, so it makes at least some sense to use draw:: to bind, depending on how you look at it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
After writing graphics code since the late 80s, I'm not quite sure what you are attempting to achieve other than code purity. Raster - draw into the backing bitmap using primitives, slap it into the display buffer. Move along. Vector - never had the need for it, overly complicated, could use raster all day long. Mind you, I was almost always working on a fixed resolution display. Examples: - customer had a 1280x104 monitor as dictated by the contract. I did not go out of my way to hard code stuff. - customer had 1024x768, 800x600, 320x240 - all of which required raster operations for performance. Might I suggest you are overthinking? Don't get me wrong, if you want to be flexible enough to target every random device that hits your market, knock yourself out.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
After writing graphics code since the late 80s, I'm not quite sure what you are attempting to achieve other than code purity. Raster - draw into the backing bitmap using primitives, slap it into the display buffer. Move along. Vector - never had the need for it, overly complicated, could use raster all day long. Mind you, I was almost always working on a fixed resolution display. Examples: - customer had a 1280x104 monitor as dictated by the contract. I did not go out of my way to hard code stuff. - customer had 1024x768, 800x600, 320x240 - all of which required raster operations for performance. Might I suggest you are overthinking? Don't get me wrong, if you want to be flexible enough to target every random device that hits your market, knock yourself out.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
The arbitrary pixel formats for bitmaps is already baked into my library. The native pixel format for all of my vector graphics is RGBA8888 (32-bit RGBA). Raster has no native format. It can draw in any format. I had to limit the vector graphics canvas to one color model and bit depth both to enforce that it always has an alpha channel for the pixel as well as to simplify design and use. Vector graphics can do things like source dodge colors, not just strict alpha blending so there's additional complexity. I decided to forgo all of that and fix the pixel format to RGBA8888 The reason I went with vector graphics is both to support SVG and as important to allow for anti-aliased graphics. My raster cannot do it, because it *can* alpha-blend. Unfortunately algorithms like the Wu algorithm don't work with alpha-blending. The only solution I've found is full vector graphics. Fortunately 32-bit MCUs can handle it, as long as you don't go crazy with it. But yeah, this library is kind of for every random device that hits the market. It runs on PC Arduino ESP-IDF Zephyr Pretty much anywhere C++17 can compile
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The arbitrary pixel formats for bitmaps is already baked into my library. The native pixel format for all of my vector graphics is RGBA8888 (32-bit RGBA). Raster has no native format. It can draw in any format. I had to limit the vector graphics canvas to one color model and bit depth both to enforce that it always has an alpha channel for the pixel as well as to simplify design and use. Vector graphics can do things like source dodge colors, not just strict alpha blending so there's additional complexity. I decided to forgo all of that and fix the pixel format to RGBA8888 The reason I went with vector graphics is both to support SVG and as important to allow for anti-aliased graphics. My raster cannot do it, because it *can* alpha-blend. Unfortunately algorithms like the Wu algorithm don't work with alpha-blending. The only solution I've found is full vector graphics. Fortunately 32-bit MCUs can handle it, as long as you don't go crazy with it. But yeah, this library is kind of for every random device that hits the market. It runs on PC Arduino ESP-IDF Zephyr Pretty much anywhere C++17 can compile
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix