|
dandy72 wrote: That doesn't mean in any way however that a male with that skill set is somehow "wrong"
I've been fascinated with knitting/crochet since I was a little kid. My great-grandmother crocheted a lot, and she taught my mother. Ironically, my daughter learned both from her mother-in-law, and is now teaching me.
Software Zen: delete this;
|
|
|
|
|
too repetitive
camping and fishing are my adventures in applied knotting
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
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 generator utility, and my web guy isn't really available to me right now.
So it's a big change. I'm eager to release, and at the same time I want to be cautious and have all my ducks in a row.
As important, I want to add significant value to a major version change, from the perspective of the users of my lib.
Trouble is, my library already does quite a bit, and I'm sort of out of ideas. I considered adding a couple of tweaks to bitmaps, but there was nothing pressing.
Have you ever run into a situation like this? Especially if it's an open source project or otherwise project you own? What do you do? I'm about paralyzed with this, and i feel like i've got competing goals i can't reconcile.
And in terms of adding value, if anyone has ideas, I'd be interested. Just concepts. One big thing I wanted to add was anti-aliased draws, but I have not figured out how to combine that with alpha-blending using the algorithms i understand without either (a) ruining alpha-blending or (b) using a lot more memory. so i've shelved that.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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 | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
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. 
|
|
|
|
|
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.
modified 29-Aug-24 14:00pm.
|
|
|
|
|
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  .
Software Zen: delete this;
|
|
|
|
|
...that the binary value 00000100 is not, in fact, 0x00000100.
It's the least of the bug I wrote in this code and this makes me think. Send positive thoughts.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
Base 2, Base 16, who's counting...
|
|
|
|
|
You can be sure it is positive if it starts with 0x0 (and contains any subsequent non-zero)!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Close enough for government work! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
And Mars landers
"Mistakes are prevented by Experience. Experience is gained by making mistakes."
|
|
|
|
|
And, evidently, anything made by Boeing.
|
|
|
|
|
1x1=2 in a math exam... 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 28-Aug-24 17:02pm.
|
|
|
|
|
What's the correct English spelling of the word that means something is fake, [Foe-nee]?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Phony
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Phoney is the UK English/AUS/NZ spelling Phony is American
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
aka English-Traditional vs English-Simplified.
|
|
|
|
|
I always have trouble with this spelling because it looks like it means, "of or pertaining to a telephone."
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
