Code telepathy
-
I have a gradient structure in SVG that has all the data necessary for rendering, but in order to create it I actually need more information than the structure contains to begin with - like bounding information for the gradient. If I add the data to the structure it will increase the memory requirements for my SVG across the board. I need to figure out a way to transfer the information I'm only using for creating the gradient structure to the point in my code where the shapes get built without modifying my core svg_gradient structure. It's such a stupid problem, and if wouldn't have worked this way if I was the one that designed it initially, although admittedly the way it works presently probably has a lower memory footprint than what I would have designed. The gradient thing is taking longer than all of the rest of it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I have a gradient structure in SVG that has all the data necessary for rendering, but in order to create it I actually need more information than the structure contains to begin with - like bounding information for the gradient. If I add the data to the structure it will increase the memory requirements for my SVG across the board. I need to figure out a way to transfer the information I'm only using for creating the gradient structure to the point in my code where the shapes get built without modifying my core svg_gradient structure. It's such a stupid problem, and if wouldn't have worked this way if I was the one that designed it initially, although admittedly the way it works presently probably has a lower memory footprint than what I would have designed. The gradient thing is taking longer than all of the rest of it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
"Any problem can be solved with enough layers of indirection." :laugh: :laugh: :laugh:
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
I have a gradient structure in SVG that has all the data necessary for rendering, but in order to create it I actually need more information than the structure contains to begin with - like bounding information for the gradient. If I add the data to the structure it will increase the memory requirements for my SVG across the board. I need to figure out a way to transfer the information I'm only using for creating the gradient structure to the point in my code where the shapes get built without modifying my core svg_gradient structure. It's such a stupid problem, and if wouldn't have worked this way if I was the one that designed it initially, although admittedly the way it works presently probably has a lower memory footprint than what I would have designed. The gradient thing is taking longer than all of the rest of it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Gradients can be a slippery slope (pun or no pun intended) without some sort of mathematical definition/formulation. Easier said than done, though.
"A little time, a little trouble, your better day" Badfinger
The good news is I don't have to come up with my own. SVG dictates all of that mess. The bad news is I can't just come up with my own. SVG dictates all of that mess. :) Fortunately, I have a reference implementation (ugly, unmaintained C code, but it works) I'm just rearchitecting it and separating concerns of parsing and building the document, such that I can build the documents programmatically - initially the code was just a parser and a rasterizer, so I refactored about 5000 lines, and started producing builder interfaces. I'm debating about replacing the parser code to use my builder code instead of building the end structures itself as i'm kind of duplicating efforts there. On the other hand, the parser needs a lot more information like tag ids and stuff that aren't used in the final structures, so I need to make up my mind on that score. But that's another can of worms. Right now I just need to get the gradients to work, but I bring up the parser, because the parser is where all of that gradient logic currently resides, and oh boy is it ugly. So this is fun. And I've got a cold, so my ability to focus has been compromised, but I need to keep occupied right now or I'll just be miserable.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
"Any problem can be solved with enough layers of indirection." :laugh: :laugh: :laugh:
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
I figured it out. What I did in this case, is sort of create structures that shadow my final structures, keeping the same data as the final structures, plus additional data. These structures are used for building the document, and thrown away once the associated shape structures that use them are inserted into the final shape list for the SVG rasterizing engine. So now instead of creating an svg_gradient you're creating an svg_gradient_info. However, to do this, I "poisoned" my structures all the way up to svg_shape_info - basically what I mean by that, is I had to spin off these shadow/"info" structures all the way up the hierarchy. It's somewhat unfortunate, but no less efficient than anything else I would have had to do, and the usability of it is what I need.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The good news is I don't have to come up with my own. SVG dictates all of that mess. The bad news is I can't just come up with my own. SVG dictates all of that mess. :) Fortunately, I have a reference implementation (ugly, unmaintained C code, but it works) I'm just rearchitecting it and separating concerns of parsing and building the document, such that I can build the documents programmatically - initially the code was just a parser and a rasterizer, so I refactored about 5000 lines, and started producing builder interfaces. I'm debating about replacing the parser code to use my builder code instead of building the end structures itself as i'm kind of duplicating efforts there. On the other hand, the parser needs a lot more information like tag ids and stuff that aren't used in the final structures, so I need to make up my mind on that score. But that's another can of worms. Right now I just need to get the gradients to work, but I bring up the parser, because the parser is where all of that gradient logic currently resides, and oh boy is it ugly. So this is fun. And I've got a cold, so my ability to focus has been compromised, but I need to keep occupied right now or I'll just be miserable.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I have a gradient structure in SVG that has all the data necessary for rendering, but in order to create it I actually need more information than the structure contains to begin with - like bounding information for the gradient. If I add the data to the structure it will increase the memory requirements for my SVG across the board. I need to figure out a way to transfer the information I'm only using for creating the gradient structure to the point in my code where the shapes get built without modifying my core svg_gradient structure. It's such a stupid problem, and if wouldn't have worked this way if I was the one that designed it initially, although admittedly the way it works presently probably has a lower memory footprint than what I would have designed. The gradient thing is taking longer than all of the rest of it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
i know you have it working, and I think your solution is not to far off from this… This reminds me of working with Windows GDI Brush objects. They were standard fill patterns, but you had to “realize” the brush against your target GDI context before you could use it to fill a shape on that context.