|
I get that. But that's a naive approach and could potentially perform a lot better than that, particularly when combined with dirty rects.
An example. My window isn't fixed size. Let's say I have 100 pixels. I can arrange that in any rectangle that's <= 100 in area.
Because of that, I can potentially avoid drawing controls twice or more, which you'd have to do in a lot of cases with a fixed window because controls will overlap more than one the window/viewport. I make the viewport the shape of what I'm drawing.
Or so I think, but it's one of those things I can't refine and verify without trying to code it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
OK, combine with dirty rectangles:
- Calculate a bounding box for all the "dirty rectangles".
- Position the viewport so that a maximal (or at least a non-zero) area of "dirty rectangles" is visible. Note that you may ignore anything outside the bounding box - it doesn't need redrawing.
- Redraw the visible parts of any dirty rectangles (i.e. those inside the viewport).
- Mark any fully visible "dirty rectangles" as "clean".
- Clip any partially-visible "dirty rectangles" to the exterior of the viewport (i.e. what remains is the part that is not visible in the viewport). Note that this may involve splitting a clipped "dirty rectangle" into a few subregions, each rectangular, e.g. if a rectangle overlaps more than one side of the viewport.
- If any "dirty rectangles" remain, go to step 1.
This will require controls in clipped "dirty rectangles" to be drawn more than once, but there is no way around this.
An algorithm for positioning the viewport is left for the alert reader. Note that this algorithm requires access only to the "dirty rectangle" list, so it should be quite fast.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Thanks for this. I'm a bit too tired to grok it fully but I've copied it to notepad for later perusal.
To err is human. Fortune favors the monsters.
|
|
|
|
|
What if... you had no overlapping controls? This would ofc require extra work on layout, and splitting the draw rects of some controls into more than one rect (or even splitting them into more controls). I realise that at a late stage of a project, this is hardly feasible, so it might be more of a hypothetical question.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
This library is too general purpose to impose those kinds of layout restrictions. It would be very difficult to use if I imposed the limitation that controls could not overlap.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Yeah, I am not exactly surprised.
But I am surprised though as you seem to be answering all sorts of posts 24/7, if you don't mind my asking, do you ever sleep?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I sleep 4 hours at a time, so I'm up a lot, and at strange hours.
To err is human. Fortune favors the monsters.
|
|
|
|
|
if ... the controls are not movable by the user, and, the graphic context is not having resolution changes ...
can you save the extent when the controls are instantiated ?
ยซThe mind is not a vessel to be filled but a fire to be kindledยป Plutarch
|
|
|
|
|
The controls are moveable but they usually will not be moved, so it may be possible to cache the results of at least part of what I'm computing. It also might be beneficial.
However, the biggest bottleneck is display I/O and the biggest constraint I have is memory, so really the part I have to get right first is how to draw to the display the least amount of times using a relatively small bitmap as my draw surface, and rendering over and over as I move through different parts of the display.
To complicate matters the size of the bitmap isn't necessary to be fixed. Basically if I allocate 100 pixels, I can create a bitmap of any size that's a total area of 100 pixels or less, so through optimization, I can potentially avoid redrawing controls more than once.
However, these things need to be tied together so it works properly. I can't just add the second optimization after the fact. I'd have to rewrite all of it.
That's the primary challenge I'm facing.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Wordle 610 4/6
๐จโฌโฌโฌโฌ
โฌโฌโฌ๐ฉโฌ
โฌโฌ๐จ๐ฉ๐ฉ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
|
|
|
|
|
Wordle 610 3/6
๐จโฌ๐ฉโฌโฌ
โฌโฌ๐ฉ๐ฉโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
|
|
|
|
|
Wordle 610 4/6*
โฌโฌ๐ฉ๐ฉโฌ
โฌโฌ๐ฉ๐ฉโฌ
โฌโฌ๐ฉ๐ฉโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
"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!
|
|
|
|
|
โฌโฌโฌโฌโฌ
โฌ๐ฉ๐ฉโฌ๐จ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming โWow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 610 6/6
โฌโฌ๐จโฌโฌ
โฌ๐ฉโฌ๐ฉโฌ
โฌ๐ฉโฌ๐ฉโฌ
โฌ๐ฉโฌ๐ฉโฌ
โฌ๐ฉโฌโฌโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Not an easy one.
|
|
|
|
|
Wordle 610 4/6
โฌโฌ๐ฉโฌโฌ
๐จโฌ๐ฉโฌโฌ
โฌโฌ๐ฉ๐ฉโฌ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 610 4/6
โฌ๐จ๐จ๐ฉโฌ
โฌ๐จ๐จ๐ฉโฌ
โฌโฌ๐จ๐ฉ๐ฉ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ
tricky
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
#Worldle #393 2/6 (100%)
๐ฉโฌโฌโฌโฌโก๏ธ
๐ฉ๐ฉ๐ฉ๐ฉ๐ฉ๐
https://worldle.teuteuf.fr
had to use map and even then it was not easy.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I was sick of contacting travis-ci every month to force my credits for my builds to renew on a supposedly free service, so with a little help I migrated my stuff over to github's actions and it works like a charm.
can recommend!
To err is human. Fortune favors the monsters.
|
|
|
|
|
Missing endorsement.
..and why not simply a script for automating builds?
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I do use scripts, within the actions.
It not only builds when I check in, it runs my tests
and if they all pass, and my library version has been incremented then it publishes a new revision to the PlatformIO library repository.
Edit: The other nice thing about actions is every build/test cycle is run on a brand new install of everything, so it's clean. You don't get that with the method you're talking about.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: It not only builds when I check in, it runs my tests So do I, using a batch file, and I get the results of that by mail every day.
honey the codewitch wrote: Edit: The other nice thing about actions is every build/test cycle is run on a brand new install of everything, so it's clean. You don't get that with the method you're talking about. That does sound like a nice improvement
Thanks for the tip.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
No problem. You have to learn a little YAML to use it, but you can also control everything from anywhere you can log into github.
Also I'm finicky about my workflow, and prefer my IDE handle checkin for me. So for me, not having to run a batch file is a win, because I just go through the check in process, and github picks it up for me, compiles, tests, etc.
Also deploys it.
It's just nice to have everything at a click.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Bigfoot is sometimes confused with Sasquatch. Yeti never complains.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
That's abominable!
|
|
|
|
|
Good one
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|