|
My graphics library for embedded devices has to deal with pixel formats I don't know ahead of time because the devices are diverse, and in order to be efficient pixels must be represented in their native bit format at all times. In other words, a pixel should store its values in whatever underlying format best suits the device or data stream
To complicate things, not all channels are color channels, (think alpha channel for transparency) and not all channels are the same bit width. (rgb565 16 bit color for example)
There are also totally weird ones that are common like rgb666/18 bit format (262,144 colors)
And not all devices use the same byte order in their streams.
To complicate things further, not all devices use an RGB color model. To my surprise I found out that some devices are BGR, regardless of byte order. Meanwhile, JPEGs are (IIRC) CMY or CMYk! Also critical because that's the input format from cameras, which are commonly used with these devices.
What is a pixel?
It's color space, which includes color model. It's binary layout. It uses potentially highly heterogenous channels for its data.
A pixel is as complicated as a unicode character! 
And I can't be messing with most of this in RAM, nor at runtime. Nope, most of it needs to be not only resolvable at compile time, but the dead code generated from all the metaprogramming involved needs to be removable by the compiler to avoid code bloat on these tiny devices.
One example is retrieving values, which I have generic getters and setters for (using metaprogramming) that generate the necessary masks and shifts at compile time based on the variable series of pixel_channel_traits you gave it and channel index, each which have their own bit depth, so retrieving and setting the channels individually gets complex.
My code can resolve it all at compile time. I feel like a hero. 
I wouldn't need to do this if there was some sort of unified driver model for these things.
But all the meta programming in C++ is cool. I really hadn't caught up with C++11 variadic templates and such until now. They're neat!
An rgb565BE pixel definition:
typedef pixel_channel_traits<uint8_t,5,pixel_channel_kind::color> color5_channel_traits_t;
typedef pixel_channel_traits<uint8_t,6,pixel_channel_kind::color> color6_channel_traits_t;
typedef pixel_traits<
uint16_t, pixel_color_model::rgb,
false, color_5_channel_traits_t, color_6_channel_traits_t, color_5_channel_traits_t> rgb565be_traits_t;
This actually generates proper getter and setter methods off the int_type, and gives you a union between the int type, and an array of bytes representing the data. It's complicated and weird code - and all of the pixel template classes (above are *trait* classes associated with the pixel template classes) which add indexed getter and setter methods for the channels that get/set a floating point value between 0 and 1, so you can operate on them generically regardless of format if you need to which is useful for things like color conversion. 
Real programmers use butterflies
modified 13-Mar-21 5:29am.
|
|
|
|
|
honey the codewitch wrote: Meanwhile, JPEGs are (IIRC) CMY or CMYk!
Variations of YCbCr - Wikipedia[^]
|
|
|
|
|
Whoops, mea culpa
*adds yet another enumeration entry to the color model*
thanks for catching that!
Real programmers use butterflies
|
|
|
|
|
Did you read the standard I posted? The Lounge[^]
It's all there, block sequences, encoding and everything.
Incredibly boring, but complete afaik.
|
|
|
|
|
User: "Can you make that button green?"
Normal developer: "Sure, no problem."
You: "Well..."[^]
|
|
|
|
|
Sander Rossel wrote: User: "Can you make that button green?"
No, I do development, not design.
Always kept away from colors and made those configurable.
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 came across this article. Is Xamarin really dead? If so, aside from MAUI, what other options are there for Mobile development?
I'm planning on doing an Android app, and I like working in Visual Studio.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I was under the impression that MAUI effectvely is Xamarin Forms evolved. So I guess if you need to code now then go for the most recent platform you can: MAUI or Xamarin Forms.
Er.... I think. Correct me if I'm wrong anyone. I'm still trying to get my head round Microsoft's future platforms.
|
|
|
|
|
From Feature Roadmap · xamarin/Xamarin.Forms Wiki · GitHub[^] as of 1st March:
Transition to .NET MAUI
July 15, 2020 Pull Request Policy Changes
As noted below, Xamarin.Forms 5.0 is due out at the end of September. At that time we will re-sync dotnet/maui and work on preparing our first preview release of .NET MAUI. In order to be considered for release by or before Xamarin.Forms 5.0, feature pull requests should be submitted for review by July 15.
After July 15, any new feature pull requests may still be submitted to this repository (xamarin/xamarin.forms). We will label those for migration to dotnet/maui. Be aware that the bulk of renderer refactoring will happen after Xamarin.Forms 5.0, so contributions to controls and renderers may require refactoring.
Pull requests to fix issues will continue to be reviewed through November 2022, and sync'd with dotnet/maui using a combination of automation and manual implementation.
The text above has now been replaced with this:
Current Version
Xamarin.Forms 5.0.0 is the current stable release. Release notes
We will continue to service Xamarin.Forms 5 through November 2022.
Next Major Version - .NET 6
The development of our next major version is underway at dotnet/maui. .NET MAUI will ship with .NET 6, now in preview.
Your existing and new Xamarin.Forms applications will migrate to .NET MAUI with tooling assistance and documentation which we will provide later in the .NET 6 preview timeframe.
Also see MAUI in .NET 6: Xamarin.Forms Does Desktop, but Not Linux or VS Code -- Visual Studio Magazine[^].
|
|
|
|
|
Thank you!
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
Kevin Marois wrote: Is Xamarin really dead?
Yes.
Failed marketing.
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.
|
|
|
|
|
Marketing alone can't bridge failed effort.
I've considered picking up Xamarin for 3 different projects during the course of it's existence. Never did.
The appeal of Xamarin was having a C# compatible front-end that could replace SilverLight in the LoB space.
In theory, XAML components could be written and tested for WPF desktop use, and then be ported to mobile platforms with low overhead costs.
Or, to put it pragmatically: it made Android and iOS expansion look cheap if you where doing WPF at the time.
In practice, the benefits just never materialized.
They used Mono as their C# framework, which is probably what killed them in the end. Mono is great for running arbitrary C# code, but it doesn't support WCF and a bunch of other business-oriented one-offs that are cheaper to propagate than to replace.
Their XAML was a dialect, so none of the major XAML designers could create Xamarin compatible components, making the use of XAML entirely pointless from a budget perspective.
At the time, I really thought they would contribute to XAML Standard 1.0, or at least align with a XAML designer.
But, as time went on, it seemed like they doubled-down on their core-value without ever really having one.
|
|
|
|
|
You need to consider that the article is written by a services company that wants it dead. Of course it will find all sort of reasons (some far from the truth: Xamarin developers hate it, Rider is the editor, really?!) that is dead and point you to the direction it wants - from their website, flutter and native.
Viewing the issue objectively, I think the future of Xamarin is in-line with the future of .NET - unifications - and it will not just die (as some might want). If that is called Xamarin, MAUI or whatever, that's just marketing term.
Obviously, things change as they evolve and some things might be dropped but I highly doubt it Xamarin Forms based apps will just stop working or won't be migrated.
It comes down to: would you trust Microsoft or foresightmobile for the future of Xamarin? I bet on Microsoft.
Eusebiu
|
|
|
|
|
"It comes down to: would you trust Microsoft or foresightmobile for the future of Xamarin? I bet on Microsoft.".
Microsoft may be a better bet but that doesn't mean that you might not someday still be left behind.
Microsoft technologies that I used in the 90s and 00s that got dropped after we had committed years of development to them include:
Visual C++ cross-compilation to Mac
Visual J++ (and the Microsoft JVM)
Visual Basic 6.
|
|
|
|
|
Quote: Microsoft technologies that I used in the 90s and 00s that got dropped after we had committed years of development to them include:
Visual C++ cross-compilation to Mac
Visual J++ (and the Microsoft JVM)
Visual Basic 6.
Don't get me started. I'm a VB.NET web developer. After years of being told that language selection was a "life-style choice", I'm now being told that for web development C# is the only option moving forward.
--A. Lovhaug
|
|
|
|
|
I wasn't very excited about the switch to C# but it ended up taking about 3 days.
|
|
|
|
|
MadGerbil wrote: I wasn't very excited about the switch to C# but it ended up taking about 3 days.
I could, but my plan is to go a different route as I'm a freelancer and my customers don't care about the technology choices. Instead, I intend to switch to RemObjects Mercury, which is almost fully compatible with VB.NET, plus supports many platforms, including ASP.NET Core, WASM, iOS, Android, and Linux development. Currently in beta, and the company is very responsive.
--A. Lovhaug
|
|
|
|
|
|
I don't think it got to mainstream - WPF which is also present "evolved" into Xamarin Forms, WinUI/UWP/MAUI and also into Uno (which in my opinion is the most complete one). So, those skills are not dead if one wants to continue with XAML/C#!
If you ask me, Silverlight was killed by HTML5/CSS3.
Eusebiu
|
|
|
|
|
Any technology comes to an end due to various reasons but Microsoft always provided ways forward (maybe with technologies that did not make it to mainstream).
Eusebiu
|
|
|
|
|
|
Use Flutter. Even that article suggests so. You can code Flutter using Visual Studio Code, which is one of the most popular editor right now.
|
|
|
|
|
I actually enjoy reading C++ reference documentation because of all the plot twists. Take for example:
A constexpr function must satisfy the following requirements:
it must not be virtual (until C++20)
Way to bury the lede guys! So the compiler can call virtual functions at compile time in C++ 20?
Or wait. Maybe (slightly) more sane, it can eliminate virtual calls to a target class altogether if that virtual can be made constexpr?
 
I don't know if I should be elated or terrified for what they've done to C++
Real programmers use butterflies
|
|
|
|
|
I believe constexpr means that the value can be computed at compile time. I guess this could apply even to virtual functions, with the value placed in, and accessed from, the vtbl.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
