|
Don't optimize until you have to generally.
But that can sometimes backfire, like when an optimization requires an architecture change.
To save memory and remain flexible, my SVG engine writes its SVGs out using callbacks with color runs and coordinates.
The exception is when
A) your canvas bounds are the same as the bound bitmap bounding box
B) the bitmap is RGBA8888 (32-bit pixels)
I just added an optimization to do direct writes in lieu of using callbacks. It greatly speeds up rendering - if you have the memory for it.
Despite being a totally different way of rendering, I exposed it through a relatively common interface, and automatically direct bind to targets that fulfill A and B:
template<typename Destination>
struct xdraw_canvas_binder {
static gfx_result canvas(Destination& destination, const srect16& bounds, ::gfx::canvas* out_canvas) {
::gfx::canvas result((size16)bounds.dimensions());
gfx_result gr = result.initialize();
if(gr!=gfx_result::success) {
return gr;
}
using st_t = xdraw_canvas_state<Destination>;
st_t* st = (st_t*)malloc(sizeof(st_t));
if(st==nullptr) {
result.deinitialize();
return gfx_result::out_of_memory;
}
st->dest = &destination;
st->dim = (size16)bounds.dimensions();
st->offset = bounds.point1();
*out_canvas=gfx_move(result);
out_canvas->on_write_callback(xdraw_canvas_write_callback<Destination>,st,::free);
out_canvas->on_read_callback(xdraw_canvas_read_callback<Destination>,st,::free);
return gfx_result::success;
}
};
template<>
struct xdraw_canvas_binder<bitmap<rgba_pixel<32>>>
{
static gfx_result canvas(bitmap<rgba_pixel<32>>& destination, const srect16& bounds, ::gfx::canvas* out_canvas) {
::gfx::canvas result((size16)bounds.dimensions());
gfx_result gr = result.initialize();
if(gr!=gfx_result::success) {
return gr;
}
using st_t = xdraw_canvas_state<bitmap<rgba_pixel<32>>>;
st_t* st = (st_t*)malloc(sizeof(st_t));
if(st==nullptr) {
result.deinitialize();
return gfx_result::out_of_memory;
}
st->dest = &destination;
st->dim = (size16)bounds.dimensions();
st->offset = bounds.point1();
*out_canvas=::gfx::helpers::gfx_move(result);
if(bounds==(srect16)destination.bounds()) {
gr=out_canvas->direct_bitmap_rgba32(&destination);
if(gr!=gfx_result::success) {
return gr;
}
} else {
out_canvas->on_write_callback(xdraw_canvas_write_callback<bitmap<rgba_pixel<32>>>,st,::free);
out_canvas->on_read_callback(xdraw_canvas_read_callback<bitmap<rgba_pixel<32>>>,st,::free);
}
return gfx_result::success;
}
};
Here I have a specialization for a general bind and one that binds directly if your pixel format is rgba_pixel<32>
I can then invoke to appropriate method with this lil guy:
template<typename Destination>
static gfx_result canvas(Destination& destination, const srect16& bounds, ::gfx::canvas* out_canvas) {
return xdraw_canvas_binder<Destination>::canvas(destination,bounds,out_canvas);
}
Because I did that, I don't need to change any code that uses ::gfx::draw::canvas<>
Radically different ways of writing, and template specializations to the rescue once again.
A little planning up front led me here, and paid for itself in spades.
Now I have transparent optimization without changing the surface area of my API, even hiding a radical departure in terms of what its draw target is (callbacks vs bitmap writes)
Anyway, as a general rule, I do an optimization pass during many of my design iterations (not version iterations, but process iterations) to make sure I'm not painting myself into a corner. When I do this I assume everything in a critical codepath will need to be optimized. Then I ask myself, "what would that look like and what impact would it have on the final architecture", and I design with that in mind, as I did here.
It's part knack, part luck, and part experience, but optimization shouldn't entirely be ignored during the design phase IMO. Don't optimize, but ask yourself what would optimization do to the design if it has to happen? and then mitigate that in the design.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Nordic just released a WiFi6 capable embedded radio. The Espressif ESP line of chips have WiFi, albeit older.
The trajectory seems to be connected IoT devices doing more and more.
HTML5 is relatively simple. It can be processed top down for the most part. They did a good job cleaning up HTML4 and making the spec more coherent. It's already what I'd consider mostly appropriate for embedded.
CSS, not so much, and it's where I'd like to see some kind of formalized standard for a CSS subset compatible with forward only processing.
What's the value in this? Frankly, being able to run web interfaces on sub ARM Cortex A chips opens the web up to far more affordable hardware. An ESP32 devkit with an integrated screen costs $18 on amazon. An RPi with no screen is in the ballpark of $100. They're different kits entirely, but I'm talking about the little guys.
Currently to make a connectible device talk to the web it requires a dedicated UI for that web app, and usually a REST or MQTT based communication on the back end. What if you could provide your simple UI from online sources that update all devices immediately when the back end changes? just for example.
CSS is the big blocker, in my experience, because of the DOM requirement. Simply choosing the right subset of selector syntax for embedded would be wonderful, but they can probably remove some of the heavier features such as font and image embedding as well.
I think what will *probably* happen instead is the price on webkit capable devices will bottom out, and then everything will have 128MB of DDR3 or better instead of 512KB of SRAM. That will solve the problem too, but is much more power hungry.
I think it's nice when a capabilities problem can be largely solved by pruning and spinning off an existing standard. I think it's possible with web stuff.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
An interesting thought.
Are you suggesting also dropping the Javascript virtual machine from the client environment also?
A real back to basics web page with no CSS and no interactivity via Javascript?
|
|
|
|
|
I think so, short of IoT MCUs being able to interpret JS** which isn't very realistic.
Still having it presented declaratively and on the web as HTML5/CSS as stripped down as it may be for embedded:
A) Should reduce cost of development, as you can hire people to do basic HTML and CSS (EDIT: see notes) instead of knowing C or C++
B) Can potentially be a server templatized/dynamized page and spun off of a full fledged website when an embedded device hits it. This is already often done for smartphones
C) Would provide pain free UI updates that instantly roll out across all devices.
There are probably other benefits that aren't occurring to me right now, but those are some major ones I see.
** it has been done, but i think it's precompiled and uploaded, or at least semi-compiled.
CSS notes: CSS can be forward only processed if you limit the CSS selector syntax to specifying ids and classes, or maybe only slightly more complicated than that. In theory you could do like .foo/bar/baz potentially and it could still be forward only, but would be more complicated. I'd be inclined to ditch that feature, but if it was in there it wouldn't be a performance killer. Parent references would be, as well as forward searches in many if not all cases (i haven't baked it all out in my head at this point)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 32 mins ago.
|
|
|
|
|
Anyone who hates it doesn't really know it and cannot come up with a better solution to a declarative UI descriptor. And it's muuuuuch easier to hate than to learn, now ain't it?
Also, anyone who intentionally is provocative to spew hate (out of boredom or some other psychological issue) only wants to drag people down to their level because it's very, very low and misery loves company. Probably has lousy relationships in real life and is generally not liked... except by other hateful people.
Happy Friday! May the winners in life have an awesome weekend. You guys rock.
Jeremy Falcon
|
|
|
|
|
Jeremy, as a friend I must tell you that some people might consider this post to be trolling.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I'm not sure if this was a joke about CSS or about me being anti-hate. If it was a joke about CSS then here's the obligatory "ooohhhh snap".
If it's about the anti-hate thing, I can totally see that. But, for those that I'd consider winners in life, it's no less trollish to them than having to endure >50% "I hate XYZ because I hate everything" type posts.
Not sure what you meant buddy. 
Jeremy Falcon
modified 1 min ago.
|
|
|
|
|
You know what's awesome?
Just dragging the stuff you want to place into place, including docking containers, and telling stuff to scale/align accordingly and never needing to screw with some esoteric second hand declaration (that quickly goes 3rd and 4th hand) of what you could just directly see and manipulate in real time even if CSS were sitting somewhere under that hood.
But what bit of language sits under it doesn't matter because it's the car that matters.
|
|
|
|
|
Not everything is drag and drop or WYSIWYG... unless you use VB. Not sure what you're getting at.
CSS is a descriptor no different than LaTeX or postscript. Saying you can't drag and drop with it has nothing to do with the language itself.
Jeremy Falcon
|
|
|
|
|
I am by no means an expert in CSS. But I agree, it is great for using for doing layouts. I have used it a bit and it is great. But I can also see how it would be a real pain to parse to properly display the intended layout, which I believe the other post you are taking a dig at was talking about. Please keep your personal dislike of others to yourself. You are both great contributers here and I personally enjoy reading both of your stuff.
There is a reason why politics and religion are not discussed on this forum, as it tends to drive a wedge between people, so posts like this are also doing the same.
You rock also, but please stop this.
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: I am by no means an expert in CSS. But I agree, it is great for using for doing layouts. I have used it a bit and it is great. But I can also see how it would be a real pain to parse to properly display the intended layout, which I believe the other post you are taking a dig at was talking about.
As always... a tool is that is very good for a particular task doesn't specially need to remain that good in the moment you need something slightly different.
PJ Arends wrote: Please keep your personal dislike of others to yourself.
I am happy that this time I read the other messages before posting mine, I like the way you told it 
PJ Arends wrote: You are both great contributers here and I personally enjoy reading both of your stuff.
I totally agree
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.
|
|
|
|
|
I'm upvoting this even though you don't like my post. Why? I know you're not coming from a place of hate, buddy. Even though you think my post is stanky. 
Jeremy Falcon
|
|
|
|
|
PJ Arends wrote: But I can also see how it would be a real pain to parse to properly display the intended layout,
That's with any technology you don't know though. Struggling is one thing, saying you hate something because you don't know it is another. From my perspective, the lounge is where you go to read about "I hate this and that" from people who know little of what they're speaking about. When I'm learning something new, I find it silly to make "hate" my default mindset. And yet, that's what I see a lot of here. It's immature at best.
PJ Arends wrote: There is a reason why politics and religion are not discussed on this forum, as it tends to drive a wedge between people, so posts like this are also doing the same.
100% agree, man. But even outside the scope of politics, we don't discuss anything of substance here. It's Wordle, something hateful or complaining, or the occasional CCC. Every now and again, someone will talk about a good book something productive, etc. But, that's few and far, far between.
PJ Arends wrote: You rock also, but please stop this.
Fair enough, I guess I'm to the point where I've seen it all. And it seems the wrong things are what's tolerated. Like immature hatred is cool, as long as you have enough people to agree with your unfounded hate. It's all good. But pointing out that's how losers think... and we can't have that.
Jeremy Falcon
modified 2 mins ago.
|
|
|
|
|
I know how to block calls on my Android phone but that is not a great game plan here
anyone have experience with "Hiya" or "Nomorobo" software ?
The root cause is a friend in Denver uses Century Link for land line & email
the hacker got into her gmail which has my protonmail account info and I think they got my phone number from that hack
She has a Tracfone account that might be involved this seems impossible famous last words.
I am on the National Do Not Call Registry which has never worked for VOIP calls
|
|
|
|
|
This just highlights that there are so many attack vectors to learn PII.
It's impossible to prevent leakage. (unless you use an adult diaper.)
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
I build UI's for our commercial inkjet printing systems. This means a display on top of a cabinet that's the operator panel for the machine.
I really, really hate getting "screen captures" that are phone pictures. From three feet away  .
Software Zen: delete this;
|
|
|
|
|
Try looking at any of the programming forums on Reddit. Endless reams of questions about code which don't include the code, or even a screenshot of the code; instead, they include a low-res photo of their monitor with some of the code on it. 
It's a great reminder of one of the many reasons why CodeProject's QA doesn't allow pictures.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
If you want to code, but you can't take a screen shot using print screen or something you need to pack it in and find a different calling.
Maybe I'm being harsh.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
It might be that they are in a lab that doesn't have outside internet connectivity or has Reddit in particular blocked.
I do that wooden table sort of nonsense in similar situations where it's just easier to do that than to jump through all the hoops of shuttling a file from a PC/laptop to a cell phone (so as to use the cell's internet).
There are some apps that will cut/paste between cell and PC/laptop. Not always convenient/possible though.
My new favorite life hack for it is to start a draft gmail and attach the file and just leave it sitting like a temp drop box until I grab it from the other device(s).
|
|
|
|
|
Half the time there's a cat or something in the picture so you know they're taking it at home.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Gary Wheeler wrote: I build UI's for our commercial inkjet printing systems.
I've never understood how someone so nice can work in such an industry.
|
|
|
|
|
Rage wrote: I've never understood how someone so nice
Thank you  .Rage wrote: can work in such an industry
I'm afraid the consumer inkjet industry copied our business model. We sell hardware (printing press plus the inkjet) more-or-less at cost, and then make earnings on ink and maintenance. It takes years of equipment sales, ink, and service on a product line to recoup development costs and to begin making a profit.
This has been How Things Are Done in commercial printing (not just inkjet) since Gutenberg  .
Software Zen: delete this;
|
|
|
|
|
Aside from the usual gripes about the over complicatedness of CSS from a usability standpoint, I have problems with it from an implementation standpoint.
CSS requires a DOM, just like JS does. With JS it's understandable. With CSS it's because they added a lot of more or less quasi-useful "convenience" features to their selectors.
If you could only do class and id based selectors your entire document could be parsed top-down, which is much more efficient than loading it all into RAM.
Why does it matter? Because embedded things exist, and HTML is so prevalent. If it wasn't for CSS a lot more devices could render a reasonable subset of HTML5.
I think they should at least come out with a standard like say eCSS (for embedded) that's a subset for forward only processing.
CSS is illustrative of what happens when you give a standards committee nothing better to do for decades.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I think you are not the only one  
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
