Surprised at Windows Bloat

[@rt]

I don’t think I’ll ever be interested in anything that isn’t mine from the ground up.
Even for Apple iOS Apps, it was the same. Never once used any of their forms, or whatever you call them, it was all my own 2D.

There’s still a few bits of hardware I’m waiting for to get right into the Windows thing.
The animation was just a test that things worked, but I’ll certainly refer to the links here.

It’s been on my mind to rid myself of all Apple products for some time. Export all iTunes music as MP3, etc.
The very last reason to hold onto my Mac was to run Xcode for iOS Apps. I had five Apps in the store some years ago.
They were booted from devices when iOS started requiring 64 bit Apps, but always ran on my Mac because I never updated
Xcode, the SDK, or anything else, but stopped working on my (up to date) target devices of course.

I was sure an Xcode update would break everything, and the first build did report some 350 depreciated function calls,
but low and behold it’s running on the latest iOS version on a fairly new iPhone. I never thought I’d see that again.
Now there’s an educational institution willing to pay my developer subscription, so I’ll get them back into the store!

[Nominal Animal]

I don’t think I’ll ever be interested in anything that isn’t mine from the ground up.

Well, it's a matter of where you draw the line, really. I don't suppose you've written your own OS? 

Me, I like Linux, because I can make it my bitch do what I want; to conform to my needs, and not vice versa. I also like the modular approach as described in the Unix Philosophy, "Do one thing and do it well"; for most tasks, I combine several tools rather than try to solve it all in one application. I don't like frameworks (and you could say Qt, GTK+/GDK, FLTK, wxWidgets, and SDL are application frameworks), so I tend to keep my processing logic quite separate from the UI -- unless the processing logic is trivial.

Because I know I can fiddle (and have fiddled) with all parts of the software stack, from the kernel to C libraries to the various services up to widget toolkits, I don't mind choosing my "line" on case-by-case basis.  I do prefer to write my own implementations of the critical parts, because I've seen (and occasionally fixed) so many bugs that I really think most programmers should not be allowed to distribute their code.

[@rt]

I don’t think I’ll ever be interested in anything that isn’t mine from the ground up.

Well, it's a matter of where you draw the line, really. I don't suppose you've written your own OS? 

I have, but only where the hardware was mine as well, so there was no OS to begin with.

I’m also sorry to say that iOS was my favourite platform to write for, but only after abstracting access to their hardware in a manner allowing me to eventually just write in plain C, and never look at Objectionable C again.
I’m not going back there though.

[Mr. Scram]

Using libraries often means not spending weeks optimising the same thing others have already optimised. Reinventing the wheel is a common pitfall. As long as you make sure that what's you're using isn't actually crap you can save yourself quite a bit of trouble.

[Dubbie]

Some "simple" things like a database, graphics library or even a KDTree can take YEARS of work to get perfect.

I don't know why you would waste time redoing those sorts of things. Your solution is bound to be worse in almost every way.

Surely you'd rather spend the effort on the parts you are writing that are actually new?

Unless this is just a way to keep yourself busy indefinitely and never finish anything. In that case, carry on!

[@rt]

Some "simple" things like a database, graphics library or even a KDTree can take YEARS of work to get perfect.

I don't know why you would waste time redoing those sorts of things. Your solution is bound to be worse in almost every way.

Surely you'd rather spend the effort on the parts you are writing that are actually new?

Unless this is just a way to keep yourself busy indefinitely and never finish anything. In that case, carry on!

Moving the demo project from one platform to the other literally took 15 minutes,
and doing anything else would have provided an even less fair comparison between the two.

[Mr. Scram]

Moving the demo project from one platform to the other literally took 15 minutes,
and doing anything else would have provided an even less fair comparison between the two.

What exactly are you trying to demo? Because without leveraging the strong suits of a platform and taking its weaknesses into account it's not a very valuable comparison in the first place. Drawing 2D images pixel for pixel with an unoptimized homebrew engine is going to have predictable results without telling you much about what it could be.

[tooki]

I don’t think I’ll ever be interested in anything that isn’t mine from the ground up.
Even for Apple iOS Apps, it was the same. Never once used any of their forms, or whatever you call them, it was all my own 2D.

That's a terrible approach, though, for so many reasons. As others have said, libraries (especially first-party) have been extensively optimized over the years. But other huge reasons to use existing libraries/APIs include accessibility (the OS's own libraries usually give you accessibility support for free) and UI consistency (it's hugely annoying when apps use custom widgets that don't quite behave like the standard ones). So in the end, you're wasting time — time you could have spent on app features, not reinventing the wheel of the internal plumbing — to produce something that's almost guaranteed to be slower, buggier, have less functionality, and have lower usability. It's a lose-lose situation.

I worked at a software company where the lead dev decided it'd be "easier" to base all the controls off of a highly customized Win Forms text box. Jeebus H Crikes, it caused so many problems. High DPI? Broken. Screen reader? Broken. Some language versions of Windows? Broken. Undo? Broken.



Ultimately — and I say this as a general rule, not as an insult to you — I think that devs that do this frequently suffer from a sort of Dunning-Kruger effect. They think they're above-average programmers (not recognizing that the folks who write OS libraries/APIs are insanely smart) and can do it better, but in fact, they don't know what "good" is, and are actually below average. So they reinvent the wheel, but instead of round, it's 7-sided with an eccentric shaft…

[technix]

I don’t think I’ll ever be interested in anything that isn’t mine from the ground up.
Even for Apple iOS Apps, it was the same. Never once used any of their forms, or whatever you call them, it was all my own 2D.

There’s still a few bits of hardware I’m waiting for to get right into the Windows thing.
The animation was just a test that things worked, but I’ll certainly refer to the links here.

It’s been on my mind to rid myself of all Apple products for some time. Export all iTunes music as MP3, etc.
The very last reason to hold onto my Mac was to run Xcode for iOS Apps. I had five Apps in the store some years ago.
They were booted from devices when iOS started requiring 64 bit Apps, but always ran on my Mac because I never updated
Xcode, the SDK, or anything else, but stopped working on my (up to date) target devices of course.

I was sure an Xcode update would break everything, and the first build did report some 350 depreciated function calls,
but low and behold it’s running on the latest iOS version on a fairly new iPhone. I never thought I’d see that again.
Now there’s an educational institution willing to pay my developer subscription, so I’ll get them back into the store!

For Apple recent years was a huge paradigm and mode shift for them - it is now iOS leading the kernel development, Swift is now front and center instead of Objective-C, etc. No wonder low level stuff break - they just plain wont fit in the newer environment, and the glue just won’t be efficient enough. If you programmed your apps using high level libraries Apple has made it almost one recompile away from supporting 64-bit iOS devices.

Apple’s music is encoded in AAC, widely supported in most recent devices since it is so widely used.

[Nominal Animal]

folks who write OS libraries/APIs are insanely smart

No, they're not, unfortunately.  (I'm approximating "insanely smart" ≃ "one in ten thousand", so that there is approximately 750 000 of them on Earth right now.)

Some of them are experienced and create very robust, very efficient code, and others are just productive.  Very few are insanely smart.  Based on the code they produce, I'd say djb is one of the rare insanely smart ones; a lot of people dismiss him and his work right out of hand.  Most of the programmers you see in the author lists in OS development, library and compiler development, and even huge software projects, are merely very productive. Some of their code is utter crap, and a lot of their designs are fragile or inefficient.

Productive programmers concentrate on the new and interesting features, and expect others (typically system integrators and end users) to debug their code.  Yes, they're innovative and productive; but not necessarily very smart; definitely not insanely smart.  Some of them (look at e.g. systemd) even use fanboi fawning as a defence against having to fix the bugs they themselves caused, so I consider elevating developers who do not objectively deserve such, as actively harmful.

Insanely smart developers tend to produce not that much code. They seem to find a way to simplify most problems completely away; they do a lot with surprisingly little.

Some large projects like GCC and the Linux kernel are amazing, but I would not call their developers insanely smart either.  They're very, very knowledgeable. You don't need to be insanely smart to create an amazing software project, but you do need to be industrious (since a lot of development is drudge work, taking care of details), innovative (in finding ways to solve many problems with not much effort), and productive.

[@rt]

I grew up with old computers and microcontrollers, and that’s what I think the influence is.
I’d say I’m creative, persistent and focussed, but not insanely smart.

Nothing has really been written for Windows by me. I only moved a 2D demo over to MSVS, and of course,
without knowing the API, it was easy to move all 2D graphics, and just replace setpixel();, figure out how to double buffer, figure out a hardware timer, etc.
This was basically to test things work, and then I started the thread being very surprised at the comparison.
This is the actual demo on Windows 7 with i5 CPU:

It’s a fixed 480x272 window because it came most directly from Sony PSP code where it runs 60fps.
I did comment the drawing, and it is the drawing BTW. The point rotation, etc will still run fast on it’s own invisibly.

Now for iOS Quartz 2D, there was actually no set pixel function. The best you could do is draw a single unit length line,
which would require more arguments sent through the stack than a proper setpixel();.
That’s where I can grab some of my existing code to easily compare the overall technique of sending a bitmap to Windows.
None of this is the result of “I can do it better”, just “I can do it”.

[technix]

I grew up with old computers and microcontrollers, and that’s what I think the influence is.
I’d say I’m creative, persistent and focussed, but not insanely smart.

Nothing has really been written for Windows by me. I only moved a 2D demo over to MSVS, and of course,
without knowing the API, it was easy to move all 2D graphics, and just replace setpixel();, figure out how to double buffer, figure out a hardware timer, etc.
This was basically to test things work, and then I started the thread being very surprised at the comparison.
This is the actual demo on Windows 7 with i5 CPU:

It’s a fixed 480x272 window because it came most directly from Sony PSP code where it runs 60fps.
I did comment the drawing, and it is the drawing BTW. The point rotation, etc will still run fast on it’s own invisibly.

Now for iOS Quartz 2D, there was actually no set pixel function. The best you could do is draw a single unit length line,
which would require more arguments sent through the stack than a proper setpixel();.
That’s where I can grab some of my existing code to easily compare the overall technique of sending a bitmap to Windows.
None of this is the result of “I can do it better”, just “I can do it”.

Throw this thing on a Dell P2415Q 24-inch 4K monitor it would be unreadable.

[@rt]

Well I’ve done the same thing for iPhone/iPad, PSP, and even the PSION 5mx PDA now, in their native screen resolutions, so it’s kind of become a benchmark thing.

The actual program I have in mind to write, there’s no escaping assembling a bitmap for each frame, and firing off graphics frames with a timer.
If someone else wrote it, it would essentially be the same thing, but live in a form I suppose, with Windows buttons, but the dynamic 2D would still have to be there.

[@rt]

year.. ok.. I just had to set pixels in a bitmap.
It’s 24 bit, but I haven’t bothered setting colour components yet.
Thanks for replies (especially links).

[Tony_G]

I read the thread but I can't remember if you were pointed to Direct2D (it was mentioned that SetPixel is about the slowest way to achieve your goals):

https://docs.microsoft.com/en-us/windows/desktop/Direct2D/direct2d-overview

The background bitmap approach you've taken will probably get you the best minimal change cross platform code but if you move over to D2D then you'll be able to do much more with your visualizations and even things like rich text experiences and localization through DirectWrite.

However your code will become way less cross platform and be more complex, though less complex than trying to implement these things yourself.

If you really want to go the whole hog cross platform it might be worthwhile to explore OpenGL.

TonyG

[tooki]

FYI, Apple has officially changed its OpenGL support to “deprecated”. It’ll still work for another version or two of macOS and iOS, but it’s on the chopping block. They really want things in Metal (just as MS wants everything on DirectX). So OpenGL is probably not a forward-looking cross-platform solution.