|
It actually makes it more complicated, because in order to avoid sending a region to the display twice you must track the overlapping portions of the screen, draw them to an offscreen bitmap, and then draw that to the display so you only do it once.
It's really important to limit screen I/O, even at the expense of CPU. The bus on these IoT monsters is usually pretty slow. Often 1-bit serial.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I never suggested sending graphics components to the screen; only that graphics components drawn later will hide graphics components drawn earlier. I had assumed that an off-screen buffer was involved. I mention this in two of my articles: Animated-Controls-using-graphic-layers and Anatomy-of-a-UserControl-SliderControl
Gus Gustafson
|
|
|
|
|
Yeah, there's an offscreen buffer but to complicate things it is not the size of the screen, and not even a fixed size, but rather, configurable.
To err is human. Fortune favors the monsters.
|
|
|
|
|
If you keep all screen objects sorted in Z-order, you should be able to determine which object(s) overlap others, and therefore draw only the object at the top of the Z-order for that area.
There are many books / articles / ... describing the algorithm, most developed when screen I/O was much slower than it is today. They should therefore be suitable for slow devices like your IoT screens.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Yeah, my controls container is sorted in z-order like Winforms.
One wrinkle is I have a configurable or otherwise variable size bitmap to write to. I then send that bitmap to the display. Since the bitmap is smaller than the display this must be repeated several times in order to render a full screen. This will also in some cases, require a control to draw more than once during a render.
It's really complicating things.
To err is human. Fortune favors the monsters.
|
|
|
|
|
"Banding" (or perhaps "Tiling" in your case) is also a solved problem - you treat the area as a viewport. Draw all visible objects (according to Z-order), but before drawing - clip them against the viewport window. If the object is totally outside the viewport, your work is done.
You could combine this with the Z-order by placing the viewport as the "highest" object in your Z-order, so anything hidden by it doesn't need drawing. All you need to do is move the viewport around the display until all parts have been rendered.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
