Why is there so much to SVG?
-
I need my vector graphics library to be feature complete enough to render most SVG. I have that, with some compromises for embedded, such as using TTF instead of WOFF or whatever for the font formats. The trouble is there is just so much to it. You have fills, strokes, gradients, textures, fonts, paths, basic shapes, and all kinds of minutia therein. I've fleshed out my header file for my class, and it's huge, and I'm not entirely finished with it. I'd like to break it up somehow because I'm overwhelmed, but I need to get a lot of it done before I can even test a little. I pasted the class proto here, sans supporting structures to give you an idea of the mess I'm up against. I hate messes.
class canvas final {
void* m_info;
canvas(const canvas& rhs)=delete;
canvas& operator=(const canvas& rhs)=delete;
public:
typedef gfx_result(*on_write_callback_type)(const rect16& bounds, rgba_pixel<32> color, void* state);
canvas();
canvas(size16 dimensions);
canvas(canvas&& rhs);
~canvas();
gfx_result initialize();
bool initialized() const;
void deinitialize();
canvas& operator=(canvas&& rhs);
on_write_callback_type on_write_callback() const;
void* on_write_callback_state() const;
void on_write_callback(on_write_callback_type callback, void* state=nullptr);size16 dimensions() const; void dimensions(size16 value); rect16 bounds() const; rgba\_pixel<32> stroke\_color() const; void stroke\_color(rgba\_pixel<32> value); canvas\_gradient stroke\_gradient() const; void stroke\_gradient(const canvas\_gradient& value); canvas\_texture stroke\_texture() const; void stroke\_texture(const canvas\_texture& value); canvas\_stroke\_style stroke\_style() const; void stroke\_style(const canvas\_stroke\_style& value); canvas\_dash stroke\_dash() const; void stroke\_dash(const canvas\_dash& value); canvas\_paint\_type stroke\_paint\_type() const; void stroke\_paint\_type(canvas\_paint\_type value); rgba\_pixel<32> fill\_color() const; void fill\_color(rgba\_pixel<32> value); canvas\_gradient fill\_gradient() const; void fill\_gradient(const canvas\_gradient& value); canvas\_texture fill\_texture() const; void fill\_texture(const canvas\_texture& value); canvas\_paint\_type fill\_paint\_type() const; void fill\_paint\_type(canvas\_paint\_type value); stream\* font() const; void font(stream& ttf\_stream, size\_t index); float font\_size() const; v -
I need my vector graphics library to be feature complete enough to render most SVG. I have that, with some compromises for embedded, such as using TTF instead of WOFF or whatever for the font formats. The trouble is there is just so much to it. You have fills, strokes, gradients, textures, fonts, paths, basic shapes, and all kinds of minutia therein. I've fleshed out my header file for my class, and it's huge, and I'm not entirely finished with it. I'd like to break it up somehow because I'm overwhelmed, but I need to get a lot of it done before I can even test a little. I pasted the class proto here, sans supporting structures to give you an idea of the mess I'm up against. I hate messes.
class canvas final {
void* m_info;
canvas(const canvas& rhs)=delete;
canvas& operator=(const canvas& rhs)=delete;
public:
typedef gfx_result(*on_write_callback_type)(const rect16& bounds, rgba_pixel<32> color, void* state);
canvas();
canvas(size16 dimensions);
canvas(canvas&& rhs);
~canvas();
gfx_result initialize();
bool initialized() const;
void deinitialize();
canvas& operator=(canvas&& rhs);
on_write_callback_type on_write_callback() const;
void* on_write_callback_state() const;
void on_write_callback(on_write_callback_type callback, void* state=nullptr);size16 dimensions() const; void dimensions(size16 value); rect16 bounds() const; rgba\_pixel<32> stroke\_color() const; void stroke\_color(rgba\_pixel<32> value); canvas\_gradient stroke\_gradient() const; void stroke\_gradient(const canvas\_gradient& value); canvas\_texture stroke\_texture() const; void stroke\_texture(const canvas\_texture& value); canvas\_stroke\_style stroke\_style() const; void stroke\_style(const canvas\_stroke\_style& value); canvas\_dash stroke\_dash() const; void stroke\_dash(const canvas\_dash& value); canvas\_paint\_type stroke\_paint\_type() const; void stroke\_paint\_type(canvas\_paint\_type value); rgba\_pixel<32> fill\_color() const; void fill\_color(rgba\_pixel<32> value); canvas\_gradient fill\_gradient() const; void fill\_gradient(const canvas\_gradient& value); canvas\_texture fill\_texture() const; void fill\_texture(const canvas\_texture& value); canvas\_paint\_type fill\_paint\_type() const; void fill\_paint\_type(canvas\_paint\_type value); stream\* font() const; void font(stream& ttf\_stream, size\_t index); float font\_size() const; vhoney the codewitch wrote:
The trouble is there is just so much to it. You have fills, strokes, gradients, textures, fonts, paths, basic shapes, and all kinds of minutia therein.
Lots of software suffer from the checklist syndrome. The designers' / developers' / maintainers' fear is that some customer will ask: 'But can you do so-and-so? Well, if you can't, then I'll have to look for some other alternative!' In my very first project after getting my degree, the marketing people came to me with checklists from the great reviewers of our software sector: This is what they are looking for. What can we provide today, and when will you have the rest implemented? My impression is that commercial software have relaxed a little bit with checklists, but open source developers have become increasingly more determined that noone shall reject FOSS because of lacking features. (The current manual of gcc options come in three volumes, doesn't it? :-)). I use some commercial software for my home PC and private projects, and FOSS people trying to pressure me into replacing it with FOSS is regularly arguing: But can your software do this? And that? Answering: But I have never had any use for those functions! is - in these discussions - an invalid argument. Even if I never needed a function: If my software doesn't provide it, it proves my software inferior, and I am silly continuing to use it. Another field where you see this feature creep at full power is in programming languages. Once, language design was clean and manageable. Today, maybe version 1.0 doesn't include everything that all the other languages have - but by version 7.3 they certainly will! Isn't about every single programming language today 'multi-paradigm'? (Who was that stating 'Any sufficiently high-versioned standard is indistinguishable from a can of worms'? That goes for programming languages as well!) Often, you see software turned down (typically by reviewers, not potential users) on completely irrelevant grounds. To take my oldest example: For my thesis, 40 years ago, I was doing an analysis of a database project that was abandoned. One of the arguments was customers rejected a DBMS that limited a database to 4 GB size. I asked what is the largest database of the current DBMS. The biggest one was 160 MB (note that this is 40 years ago! :-)) - 4% of the limit of the new system. (That wasn't a design limitation, only the specific proposed first implementati
-
honey the codewitch wrote:
The trouble is there is just so much to it. You have fills, strokes, gradients, textures, fonts, paths, basic shapes, and all kinds of minutia therein.
Lots of software suffer from the checklist syndrome. The designers' / developers' / maintainers' fear is that some customer will ask: 'But can you do so-and-so? Well, if you can't, then I'll have to look for some other alternative!' In my very first project after getting my degree, the marketing people came to me with checklists from the great reviewers of our software sector: This is what they are looking for. What can we provide today, and when will you have the rest implemented? My impression is that commercial software have relaxed a little bit with checklists, but open source developers have become increasingly more determined that noone shall reject FOSS because of lacking features. (The current manual of gcc options come in three volumes, doesn't it? :-)). I use some commercial software for my home PC and private projects, and FOSS people trying to pressure me into replacing it with FOSS is regularly arguing: But can your software do this? And that? Answering: But I have never had any use for those functions! is - in these discussions - an invalid argument. Even if I never needed a function: If my software doesn't provide it, it proves my software inferior, and I am silly continuing to use it. Another field where you see this feature creep at full power is in programming languages. Once, language design was clean and manageable. Today, maybe version 1.0 doesn't include everything that all the other languages have - but by version 7.3 they certainly will! Isn't about every single programming language today 'multi-paradigm'? (Who was that stating 'Any sufficiently high-versioned standard is indistinguishable from a can of worms'? That goes for programming languages as well!) Often, you see software turned down (typically by reviewers, not potential users) on completely irrelevant grounds. To take my oldest example: For my thesis, 40 years ago, I was doing an analysis of a database project that was abandoned. One of the arguments was customers rejected a DBMS that limited a database to 4 GB size. I asked what is the largest database of the current DBMS. The biggest one was 160 MB (note that this is 40 years ago! :-)) - 4% of the limit of the new system. (That wasn't a design limitation, only the specific proposed first implementati
You're right, a lot of people have no idea what they need, and that SVG isn't special in its bloat. It's just overwhelming to deal with. But I really want nice pretty vector graphics for my little ARMs and stuff, and now the 32 bit ones have enough ooomph to do it. I just got sick of interfaces that look like they were crafted in the mid 1990s. LVGL seems to find its way around that, even with raster graphics, but I couldn't make heads or tails of its rendering process. I wasn't really going to do a whole vector engine, aside from loading and rendering a reasonable SVG subset which I already had finished, but not one with an exposed API you could draw with. The reason I did is I could not find efficient algorithms for doing anti-aliased draws with alpha-blending. The anti-aliasing would cause pixels to be drawn in the same place twice, which fouls alpha-blending. With vector graphics you get the mess basically as a series of polygons except all the lines are actually bezier curves. When you go to render, the way it's done, the issue above isn't an issue. But it's sort of an all or nothing deal because the latter works nothing like the former at all.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix