XYplorer Beta Club

https://stackoverflow.com/questions/713 ... dows-forms

TextRenderer.DrawText might be an option, that excludes usage in WinForms though.

Also, for the .NET part those benchmarks were done with a Release build and the debugger detached, right?

admin wrote: ↑19 Aug 2020 20:57 I just made some performance tests: Simple printing of text to a surface (there is LOT of this happening in XYplorer all the time). VB6 is 7 times faster than .NET.

Have you tried asking for advice on Stack Overflow? There are thousands of developers there, and many of them are quite eager to help others.

paludis wrote: ↑19 Aug 2020 21:58 TextRenderer.DrawText might be an option, that excludes usage in WinForms though.

Tried, and it looks like double the speed of DrawString, still too slow for me. You know, XYplorer is fundamentally a painting, fast printing is essential.

Then I learned that .NET has no AutoRedraw, and no Control arrays. And developers in the web are showing complicated ways how to emulate this. Sorry, but that's a joke.

So what do you call XYcopy as a way of getting round the fact that VB has no multi-threading? Or, your context menu solution for 64-bit? I call that a joke!

So we all have our laugh, the fun is back in programming.

Gandolf wrote: ↑20 Aug 2020 10:08 So what do you call XYcopy as a way of getting round the fact that VB has no multi-threading? Or, your context menu solution for 64-bit? I call that a joke!

I think that's exactly the kind of motivation we need Thank you!
Yeah, i can also confirm, that .NET is an ugly monster but VB is dead. So easy

admin wrote: ↑20 Aug 2020 10:15 So we all have our laugh, the fun is back in programming.

we've all been on the verge of giving up and going crazy. who hasn't just keep going. if one thing doesn't work, then finish one that works. this is the necessary portion that always encourages me

When the ugly is slower than the dead I'm for the dead.

Actually I should put that on the front page: Written in a dead language! The zombie's file manager. And you know, "The Dead don't Die", think about it, VB6 will never change again. It's ultimately stable and reliable.

well, the language is not important in itself. it's just, what do you do if in 10 years the 32-bit for Windows consumer dies out. Then you have to find another job. This is something you can't fix anymore. I know what it's like, believe me. I've quit a dozen times, and I've been through it.

on the other hand, the way Microsoft behaves, it could happen that 32bit never dies out. Considering that the VS IDE is only available in a 32-bit version and Microsoft is strictly against releasing a 64-bit version. This company just can't be understood. I think they dont know how to do it. an absolute joke

https://developercommunity.visualstudio ... ation.html

GitCoder wrote: ↑20 Aug 2020 10:58 on the other hand, the way Microsoft behaves, it could happen that 32bit never dies out. Considering that the VS IDE is only available in a 32-bit version and Microsoft is strictly against releasing a 64-bit version. This company just can't be understood. I think they dont know how to do it. an absolute joke

That's a very good point - and could come to our all "rescue" for the upcoming years.

Apple is used to handle such changes exactly the opposite way (transparent transformation/migration schedule, best possible support - but dead consequent execution).

Microsoft refused to release VS 64bit for the 2019 version. Doesn't mean it won't come in VSnext.

I'm sure they'll have the resources to do it when (not if) the time comes to retire x86 in Windows.

Before 32-bit Windows dies a Chinese OS will take over. But that's no problem either because they will have a 32-bit Windows emulation subsystem. 32-bit is too deeply woven into the global fabric, it cannot go away. It's not like 16-bit, those were the pioneer days. 32-bit is mainstream, foreverstream. Well, when AI takes over things will change dramatically. That will end a lot.

admin wrote: ↑20 Aug 2020 09:28 Tried, and it looks like double the speed of DrawString, still too slow for me. You know, XYplorer is fundamentally a painting, fast printing is essential.

Then I learned that .NET has no AutoRedraw, and no Control arrays. And developers in the web are showing complicated ways how to emulate this. Sorry, but that's a joke.

Yea, I'm trying to wrap my head around how VB6 WinAPI things actually work.

I think the main issue here are different concepts. Due to the single-threaded nature in VB6, one basically has to do all the work in the UI thread (e.g. reading directory contents from disk), thus you need ultra fast painting so there is time left to do actual work, otherwise the UI would stutter or freeze.

In WinForms one is not so dependent on ultra fast repainting, because if something is not fast enough to be handled in the UI thread, you simply do it another thread. The UI would remain unblocked and once the worker thread is done, it can feed the results to the UI thread. (Link)
You probably need to slap over quite a few controls on a form, before you need to think about drawing performance and optimization.