I came into this with a vague plan, and I don't quite know where to go with this
-
I've been working on my htcw_gfx 2.0 project and I got into the major shift for some reasons that were important to me, but maybe not the users of my library. There were parts that were brittle, and there were areas that were going to snowball if I didn't make major breaking changes before I released any major libraries dependent on it - and I already have one of those, but it's not even 1.0 yet, so I'll probably move that to 1.0 and update it right after I finish with gfx. I realized that most of what I'm doing is pruning and cleaning up. That's all great, but from an end user standpoint, it doesn't add a lot of significant value, and that's what's got me hung up, in terms of when to call it good enough and release it (breaking all existing 1.x projects in the process) I made little notes for myself in terms of what I've accomplished so far, in pursuit of making a change document, but there's not a lot there:
Major changes w/ htcw_gfx 2.0
Cutting floor:
Complete removal of driver integration, so no more "async" draw destinations, or write only draw destinations, etc, greatly simplifying the code.
Rationale: Even with those facilities in place, it's still faster to draw to bitmaps and then send bitmaps to the screen. It takes a little bit more memory, but it's always worth it.
On the other hand, the zoo that was the template specialization chains necessary to fully utilize a display device (batching, async, etc) was creating a maintenance problem.Rearrangements:
svg_doc has been superseded by svg_image
All images (png,jpg,svg) derive from a common base class (gfx::image) and you can add more
All fonts (ttf, vlw, fon) now derive from a common base class (gfx::font), and gfx::font has been superseded by gfx::win_font
Primary additions:
Text and images can now be post-processed during the render by using font.draw() and image.draw() with their respective callbacks.
Text encoding is now pluggable, and should present no huge changes for anyone, but allows for adding additional encodings other than latin1 and utf8
Of that list, I only have two primary additions and only one that is likely to be used by more than one or two people. So aside from text and image post-processing and a bit cleaner interface, what value am I really adding here? Keep in mind these changes are breaking breaking breaking, and for them to not be involves dragging along a lot of dead compatibility code on an embedded library. They even break the gfx website's header genera
-
I've been working on my htcw_gfx 2.0 project and I got into the major shift for some reasons that were important to me, but maybe not the users of my library. There were parts that were brittle, and there were areas that were going to snowball if I didn't make major breaking changes before I released any major libraries dependent on it - and I already have one of those, but it's not even 1.0 yet, so I'll probably move that to 1.0 and update it right after I finish with gfx. I realized that most of what I'm doing is pruning and cleaning up. That's all great, but from an end user standpoint, it doesn't add a lot of significant value, and that's what's got me hung up, in terms of when to call it good enough and release it (breaking all existing 1.x projects in the process) I made little notes for myself in terms of what I've accomplished so far, in pursuit of making a change document, but there's not a lot there:
Major changes w/ htcw_gfx 2.0
Cutting floor:
Complete removal of driver integration, so no more "async" draw destinations, or write only draw destinations, etc, greatly simplifying the code.
Rationale: Even with those facilities in place, it's still faster to draw to bitmaps and then send bitmaps to the screen. It takes a little bit more memory, but it's always worth it.
On the other hand, the zoo that was the template specialization chains necessary to fully utilize a display device (batching, async, etc) was creating a maintenance problem.Rearrangements:
svg_doc has been superseded by svg_image
All images (png,jpg,svg) derive from a common base class (gfx::image) and you can add more
All fonts (ttf, vlw, fon) now derive from a common base class (gfx::font), and gfx::font has been superseded by gfx::win_font
Primary additions:
Text and images can now be post-processed during the render by using font.draw() and image.draw() with their respective callbacks.
Text encoding is now pluggable, and should present no huge changes for anyone, but allows for adding additional encodings other than latin1 and utf8
Of that list, I only have two primary additions and only one that is likely to be used by more than one or two people. So aside from text and image post-processing and a bit cleaner interface, what value am I really adding here? Keep in mind these changes are breaking breaking breaking, and for them to not be involves dragging along a lot of dead compatibility code on an embedded library. They even break the gfx website's header genera
Hmm... for anti-aliased draws maybe that could be done with smaller memory footprint by breaking the framebuffer into smaller rects. Maybe it'll go janky along the seams but maybe not. Maybe implement some kind of filters similar to what Reshade does. I think this can possibly include AA. I'm not sure how useful these sorts of filters would be in context, but it is a feature.
-
Hmm... for anti-aliased draws maybe that could be done with smaller memory footprint by breaking the framebuffer into smaller rects. Maybe it'll go janky along the seams but maybe not. Maybe implement some kind of filters similar to what Reshade does. I think this can possibly include AA. I'm not sure how useful these sorts of filters would be in context, but it is a feature.
It's not necessarily that it would be seams because it's not quite like bicubic resampling, but there is a wrinkle in terms of breaking it into parts as you suggest. The issue is strictly the edges, and I end up drawing the edge pixels in the same place more than once, which if you understand how alpha blending works, utterly nukes it because the old pixel bleeds through the new one What I would need to do is just hold a bitmap to encase the edge portion i'm drawing. Maybe even like 8x8 or something really small, but where and when to do it in the code is the part I'm not sure I can wrap my head around. I should attack it more. One reason I haven't worked harder at it, is I support building SVGs directly to an in-memory binary, ready-to-render form without ever going to XML. It does all of the anti-aliasing and alpha blending but it's not as fast as I'd like.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It's not necessarily that it would be seams because it's not quite like bicubic resampling, but there is a wrinkle in terms of breaking it into parts as you suggest. The issue is strictly the edges, and I end up drawing the edge pixels in the same place more than once, which if you understand how alpha blending works, utterly nukes it because the old pixel bleeds through the new one What I would need to do is just hold a bitmap to encase the edge portion i'm drawing. Maybe even like 8x8 or something really small, but where and when to do it in the code is the part I'm not sure I can wrap my head around. I should attack it more. One reason I haven't worked harder at it, is I support building SVGs directly to an in-memory binary, ready-to-render form without ever going to XML. It does all of the anti-aliasing and alpha blending but it's not as fast as I'd like.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
What if you only AA'd something like 95% of the image? The other 5% is margin of untouched pixels between the AA rect splits? I'd expect maybe a weird sort of screen-door-like effect on the image but it might still look better than the source and the specifics might mean it's not noticeable at all.
-
What if you only AA'd something like 95% of the image? The other 5% is margin of untouched pixels between the AA rect splits? I'd expect maybe a weird sort of screen-door-like effect on the image but it might still look better than the source and the specifics might mean it's not noticeable at all.
I mean it seems like the same problem as splitting it up otherwise, in that's just confusing to know where and when to do it exactly. LVGL creates masks for everything it draws, and it's kind of the gold standard in embedded for both fast and fancy graphics. I've tried to decipher that code to get an inkling of how it works, but it's C and there are function dispatch tables and such in the rendering process that make it impossible to follow.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I've been working on my htcw_gfx 2.0 project and I got into the major shift for some reasons that were important to me, but maybe not the users of my library. There were parts that were brittle, and there were areas that were going to snowball if I didn't make major breaking changes before I released any major libraries dependent on it - and I already have one of those, but it's not even 1.0 yet, so I'll probably move that to 1.0 and update it right after I finish with gfx. I realized that most of what I'm doing is pruning and cleaning up. That's all great, but from an end user standpoint, it doesn't add a lot of significant value, and that's what's got me hung up, in terms of when to call it good enough and release it (breaking all existing 1.x projects in the process) I made little notes for myself in terms of what I've accomplished so far, in pursuit of making a change document, but there's not a lot there:
Major changes w/ htcw_gfx 2.0
Cutting floor:
Complete removal of driver integration, so no more "async" draw destinations, or write only draw destinations, etc, greatly simplifying the code.
Rationale: Even with those facilities in place, it's still faster to draw to bitmaps and then send bitmaps to the screen. It takes a little bit more memory, but it's always worth it.
On the other hand, the zoo that was the template specialization chains necessary to fully utilize a display device (batching, async, etc) was creating a maintenance problem.Rearrangements:
svg_doc has been superseded by svg_image
All images (png,jpg,svg) derive from a common base class (gfx::image) and you can add more
All fonts (ttf, vlw, fon) now derive from a common base class (gfx::font), and gfx::font has been superseded by gfx::win_font
Primary additions:
Text and images can now be post-processed during the render by using font.draw() and image.draw() with their respective callbacks.
Text encoding is now pluggable, and should present no huge changes for anyone, but allows for adding additional encodings other than latin1 and utf8
Of that list, I only have two primary additions and only one that is likely to be used by more than one or two people. So aside from text and image post-processing and a bit cleaner interface, what value am I really adding here? Keep in mind these changes are breaking breaking breaking, and for them to not be involves dragging along a lot of dead compatibility code on an embedded library. They even break the gfx website's header genera
honey the codewitch wrote:
I want to add significant value to a major version change
Maintainability is a significant value. Maybe one of the greatest of all values, because it makes it far easier to go forward. Sounds like you've done good - congratulations! :beer:
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
honey the codewitch wrote:
I want to add significant value to a major version change
Maintainability is a significant value. Maybe one of the greatest of all values, because it makes it far easier to go forward. Sounds like you've done good - congratulations! :beer:
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
It is for me, but in terms of the exposed functionality of the library, very little has changed. I want to add value for the end users, not just myself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It is for me, but in terms of the exposed functionality of the library, very little has changed. I want to add value for the end users, not just myself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
My understanding is that you are the sole developer of this library. Furthermore, users of 1.0 are not paying you for maintenance/support. Even though it's really cool that you have users and you want to make life easy for them, enhancing maintainability is an important major change (and not just for you). I think you can absolve yourself of any guilt for not including any great new features for your users in 2.0. Ease of maintenance also helps your users. Bug fixes and future new features come quicker with fewer defects. Besides, if you're going to make a breaking change better to do it between versions 1 and 2 (more understandable/forgivable) rather than 6 and 7 (though, when it needs to happen, it needs to happen). As long as releasing 2.0 doesn't force 1.0 users to upgrade they can just stay with 1.0 until it behooves them to upgrade and deal with the breaking changes. If this is true I think you can release 2.0 when you are ready. It's okay to leave the bitmap tweaks, anti-aliasing and other stuff for a later point release. (We'll hope they won't also cause breaking changes.) You just need to document that 1.0 is as complete as it will get, new users should use 2.0, and upgrades will break existing code. 2.0 doco probably should mention it breaks existing 1.0 code as well as include some examples on how to perform those changes. Just the biggies, it doesn't need to be exhaustive. (Well duh, 'nuff said, I'm preaching to the choir here.) Just my 2 cents, take it for what it's worth. :)
-
I've been working on my htcw_gfx 2.0 project and I got into the major shift for some reasons that were important to me, but maybe not the users of my library. There were parts that were brittle, and there were areas that were going to snowball if I didn't make major breaking changes before I released any major libraries dependent on it - and I already have one of those, but it's not even 1.0 yet, so I'll probably move that to 1.0 and update it right after I finish with gfx. I realized that most of what I'm doing is pruning and cleaning up. That's all great, but from an end user standpoint, it doesn't add a lot of significant value, and that's what's got me hung up, in terms of when to call it good enough and release it (breaking all existing 1.x projects in the process) I made little notes for myself in terms of what I've accomplished so far, in pursuit of making a change document, but there's not a lot there:
Major changes w/ htcw_gfx 2.0
Cutting floor:
Complete removal of driver integration, so no more "async" draw destinations, or write only draw destinations, etc, greatly simplifying the code.
Rationale: Even with those facilities in place, it's still faster to draw to bitmaps and then send bitmaps to the screen. It takes a little bit more memory, but it's always worth it.
On the other hand, the zoo that was the template specialization chains necessary to fully utilize a display device (batching, async, etc) was creating a maintenance problem.Rearrangements:
svg_doc has been superseded by svg_image
All images (png,jpg,svg) derive from a common base class (gfx::image) and you can add more
All fonts (ttf, vlw, fon) now derive from a common base class (gfx::font), and gfx::font has been superseded by gfx::win_font
Primary additions:
Text and images can now be post-processed during the render by using font.draw() and image.draw() with their respective callbacks.
Text encoding is now pluggable, and should present no huge changes for anyone, but allows for adding additional encodings other than latin1 and utf8
Of that list, I only have two primary additions and only one that is likely to be used by more than one or two people. So aside from text and image post-processing and a bit cleaner interface, what value am I really adding here? Keep in mind these changes are breaking breaking breaking, and for them to not be involves dragging along a lot of dead compatibility code on an embedded library. They even break the gfx website's header genera
The major values you are adding are: 1) Users who pick up your library now will get the new version and will get fewer breaking changes down the line. 2) Users already using your library will have longer to adapt to the new version, giving them more time to experiment with it and align it with their releases. As a developer I would not consider these two points "small". Just make sure you communicate clear what is in the release.
-
I've been working on my htcw_gfx 2.0 project and I got into the major shift for some reasons that were important to me, but maybe not the users of my library. There were parts that were brittle, and there were areas that were going to snowball if I didn't make major breaking changes before I released any major libraries dependent on it - and I already have one of those, but it's not even 1.0 yet, so I'll probably move that to 1.0 and update it right after I finish with gfx. I realized that most of what I'm doing is pruning and cleaning up. That's all great, but from an end user standpoint, it doesn't add a lot of significant value, and that's what's got me hung up, in terms of when to call it good enough and release it (breaking all existing 1.x projects in the process) I made little notes for myself in terms of what I've accomplished so far, in pursuit of making a change document, but there's not a lot there:
Major changes w/ htcw_gfx 2.0
Cutting floor:
Complete removal of driver integration, so no more "async" draw destinations, or write only draw destinations, etc, greatly simplifying the code.
Rationale: Even with those facilities in place, it's still faster to draw to bitmaps and then send bitmaps to the screen. It takes a little bit more memory, but it's always worth it.
On the other hand, the zoo that was the template specialization chains necessary to fully utilize a display device (batching, async, etc) was creating a maintenance problem.Rearrangements:
svg_doc has been superseded by svg_image
All images (png,jpg,svg) derive from a common base class (gfx::image) and you can add more
All fonts (ttf, vlw, fon) now derive from a common base class (gfx::font), and gfx::font has been superseded by gfx::win_font
Primary additions:
Text and images can now be post-processed during the render by using font.draw() and image.draw() with their respective callbacks.
Text encoding is now pluggable, and should present no huge changes for anyone, but allows for adding additional encodings other than latin1 and utf8
Of that list, I only have two primary additions and only one that is likely to be used by more than one or two people. So aside from text and image post-processing and a bit cleaner interface, what value am I really adding here? Keep in mind these changes are breaking breaking breaking, and for them to not be involves dragging along a lot of dead compatibility code on an embedded library. They even break the gfx website's header genera
We have an inhouse debugging tool I developed that we use a lot. It's been under active development since 2000. I run into the problem you describe every couple of years. I'll have let small improvements and bug fixes accumulate, and then work on the app for a while. It's tough to finally say "enough's enough". I have occasionally let the fun of working on the thing get the best of me and then I end up with features that are... gonzo. Case in point: The app has a palette of colors the user can choose from. Instead of using any of the countless color pickers out there, the app lets you pick from an image either embedded in the app or an arbitrary image you specify. It's cute, but hardly necessary :-O.
Software Zen:
delete this;
