Did you know: All GDI apps render slower under Win7?


Recommended Posts

What?? GDI and the Win32 API's are official. The Direct*D API's are not a requirement to build Windows GUI's. You do know that right?

Uh yea they are if you're wanting to build against Direct2D, what you were whining about being so difficult in the first place, hence "refusing to use the APIs"?

What?? GDI and the Win32 API's are official. The Direct*D API's are not a requirement to build Windows GUI's. You do know that right?

MSDN clearly says one should no longer use GDI for Windows programs:

Technologies that are obsolete and should not be used in new applications.

This is what MSDN says about GDI (legacy graphics).

http://msdn.microsoft.com/en-us/library/ee663279(v=VS.85).aspx

And why would I want to build against Direct2D when I'm coding in C?

And round in circles we go. Oh I don't know, programming new projects for current technology appropriate to the platform versus legacy/depreciated stuff that's getting phased out maybe? If your tools of choice aren't up to the job, it might be time to consider switching to something more appropriate to the platform.

MSDN clearly says one should no longer use GDI for Windows programs:

This is what MSDN says about GDI (legacy graphics).

http://msdn.microsof...e663279(v=VS.85).aspx

Link's busted, fixed it for you. MSDN

MSDN clearly says one should no longer use GDI for Windows programs:

This is what MSDN says about GDI (legacy graphics).

http://msdn.microsof...e663279(v=VS.85).aspx

Ignoring the fact that that page won't load, I, as a developer, wish to target both XP and Windows 7, so GDI is the best solution because it's supported on both platforms, unlike Direct2D. It's built right into the Win32 API, unlike the Direct*D interfaces, which are separate and use COM (horrible to use from most language bindings).

Ignoring the fact that that page won't load, I, as a developer, wish to target both XP and Windows 7, so GDI is the best solution. It's built right into the Win32 API, unlike the Direct*D interfaces, which are separate and use COM (horrible to use from most language bindings).

There is absolutely no excuse for sticking to plain C Win32 API any more. The whole world is moving on. C++/C# is the way forward. Plain C is simply not good enough for today's complex programming needs.

There is absolutely no excuse for sticking to plain C Win32 API any more.

That's what 99% of WIndows programs use lol.

The whole world is moving on. C++/C# is the way forward. Plain C is simply not good enough for today's complex programming needs.

No thanks. I prefer patent unencumbered programming languages like Python, Java, Perl to C#. As far as C++ goes, If I want to use a OO design pattern, again, i'll use Java or Python. I really don't see a use for C++ these days.

That's what 99% of WIndows programs use lol.

LOL! Are you living in 1993? Almost no Windows programs are written in plain-C any more.

No thanks. I prefer patent unencumbered programming languages like Python, Java, Perl to C#. As far as C++ goes, If I want to use a OO design pattern, again, i'll use Java or Python. I really don't see a use for C++ these days.

C# is the most elegant programming language in the world. That's why its popularity is rising exponentially. If you prefer native code instead, C++ is great. But Java is the worst programming language in the history of mankind. It's a complete mess, a lot like Android.

LOL! Are you living in 1993? Almost no Windows programs are written in plain-C any more.

The Win32 API, not C. Reading comprehension?

C# is the most elegant programming language in the world.

Cool story. Bro.

That's why its[C#] popularity is rising exponentially.

Really? From what I've read, It hasn't made an impact. This could be attributed to the fact that it's locked down to Windows of course. I prefer to write portable code.

If you prefer native code instead, C++ is great. But Java is the worst programming language in the history of mankind. It's a complete mess, a lot like Android.

Java is the language of choice for Android, Nuff said.

...

It's built right into the Win32 API, unlike the Direct*D interfaces, which are separate and use COM (horrible to use from most language bindings).

Uh, COM and Direct2D (And DirectWrite/Direct3D/etc.) are part of Win32.

No thanks. I prefer patent unencumbered programming languages like Python, Java, Perl to C#. As far as C++ goes, If I want to use a OO design pattern, again, i'll use Java or Python. I really don't see a use for C++ these days.

Don't tell me you've never read Gosling's explanation about how they had to patent everything at Sun, and how they made contests of who got the most stupid patent?

Fact: If someone tells you his creation is not patent-encumbered, that doesn't mean it isn't. Look at Android and WebM.

Really? From what I've read, It hasn't made an impact. This could be attributed to the fact that it's locked down to Windows of course. I prefer to write portable code.

*cough* dotGNU *cough* Mono *cough*

Also, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

*cough* dotGNU *cough* Mono *cough*

Also, http://www.tiobe.com...tpci/index.html

Both of which have fallen into disuse and have questionable compatibility with Microsoft's implementation, as evidenced by Canonical's recent decision to exclude Mono from future Ubuntu releases.

  • 1 month later...

Thanks for this post, I thought I was the only one noticing this.

I use a certain application maximized on my Windows 7 x64 workstation having upgraded from Windows XP. The application shows objects, about 200 of them on screen, and when I go to scroll, it is noticeably slower and somewhat flicky under Windows 7. Since the developer must support XP I doubt I'll see any improvement for a long time. Would be better for MS to fix this.

@Joey S and @Tilt090

not to sound rude (unlike Tilt sounds from my perspective)

but grow up and stop living in the past. Things change, in the world of technology you need to learn to adapt

So if I get this straight, an application must use D2D/DW or suffer a major performance drop on post-XP era Windows?

where are you getting the "major" from? as has been stated, it's a barely noticeable performance drop under most hardware

The most important GDI operations are hardware accelerated under Windows 7, so the majority of users wouldn't notice any slowdowns.

The main problem with using GDI rendering is that it's pretty crappy, the speed has nothing to do with it.

so its decided win7 is slower eh.. and since people will continue to develop for gdi its a no brainer to move to the faster os ... snicker snicker...

And consider how old GDI is.

GDI goes back to 9x/NT4 - and was optimized to GDI+ in ME/2K Professional.

GDI+ is a crapton faster than GDI - and that was merely in ME and Windows 2000 Professional. GDI+ had one major issue (which it still has) - backward-compatibility issues with GDI-only displays.

How many GDI-only applications are there today?

And isn't that reality still the case with those GDI-only applications that exist today? (Backward-compatibility with older versions of Windows.)

The only GDI-only application I even know of is *Opera* - which is designed with WayBack compatibility first and foremost. (Even Mozilla isn't GDI-only, and hasn't been on Windows for a while.)

Not one messaging client is GDI-only. (That includes Facebook Messenger, by the way.)

GDI+ is a software version of GDI that can do AA (One big difference), it's often quite slower than GDI.

*Often quite slower* on what hardware?

On low-end- non-accelerated onboard graphics of the G41 (Intel) or earlier sort?

*Often quite slower* on what hardware?

On low-end- non-accelerated onboard graphics of the G41 (Intel) or earlier sort?

Adding software AA to stuff makes it slower on ANY kind of hardware. the difference is wether you hardware is fast enough for you not to notice or not.

*Often quite slower* on what hardware?

On low-end- non-accelerated onboard graphics of the G41 (Intel) or earlier sort?

The GPU doesn't come into it since GDI+ runs on the CPU, you could have a GTX 570 or a simple framebuffer device, GDI+ will still be slower in most cases (GDI+ might win when it comes to 32bit textures, but only because GDI doesn't support them "well" :laugh:)

This topic is now closed to further replies.
  • Posts

    • You do you, I've just said that it first appeared in "home" version before it will be available in "work" one. I use Edge only because it still supports MV2 uBO extension even on Android - I'll switch when they stop.
    • I imagine that was a review or something? My reviews mostly contain a lot of images and galleries, but these are all webp too, but yeah it all adds up on the page load. Would help if you were more helpful with your critique instead of bitching and moaning like a Karen 😂 Because then we might be able to fix it for you.
    • If Valve refused to let them make the case, I wonder if they've already partnered with someone else to do it? The fact that they didn't seek permission/licence before diving straight in is incredible though
    • OpenClaw now has native mobile apps on iOS and Android by Karthik Mudaliar OpenClaw, the viral open-source personal AI agent, now has its own mobile app, available on both Android and iOS. Users can pair the app with an existing OpenClaw gateway and can start using new mobile-native features that are now available on the app. The app supports all the existing features you'd already have seen on OpenClaw's TUI, as well as some more, such as real-time and background Talk mode, action approvals, sharing from iOS, and optional access to device capabilities such as camera, screen, location, photos, contacts, calendar, and reminders. These features are available on both the Android and iOS versions of the app. What's important with these apps is that they don't run OpenClaw on your phone, but are actually just companion apps that require a running OpenClaw Gateway on an existing device, on macOS, Linux, or Windows via WSL2. To pair the app with your existing OpenClaw gateway, users need to run the command "/pair qr" on the TUI or existing chat interface, which brings up a QR code. Users can then scan this QR code to pair it up with the mobile app. There's also an option to manually pair the app by entering the host and a port. Previously, OpenClaw had been available on phones via WhatsApp, Telegram, Slack, Discord, Microsoft Teams, Matrix, and others. Now, with a native mobile app, the interface is much cleaner and more focused on just the OpenClaw, of course, with the added support for camera, screen, location, and more. It's important to note that OpenClaw comes with its own security warnings. There's always a chance of prompt injection with these tools, so users are recommended to double-check authentication, tool policy, sandboxing, and execution approvals rather than prompts alone. For users well-versed with the AI harness, a native mobile app makes it easier to approve an automation, share a link, use voice, or let an agent react to phone-side context.
  • Recent Achievements

    • First Post
      rosiecharles earned a badge
      First Post
    • Reacting Well
      Juan Dela earned a badge
      Reacting Well
    • Week One Done
      Collagen Project earned a badge
      Week One Done
    • Reacting Well
      Wakeen1966 earned a badge
      Reacting Well
    • Rookie
      Almohandis went up a rank
      Rookie
  • Popular Contributors

    1. 1
      +primortal
      515
    2. 2
      +Edouard
      273
    3. 3
      PsYcHoKiLLa
      143
    4. 4
      Steven P.
      99
    5. 5
      macoman
      54
  • Tell a friend

    Love Neowin? Tell a friend!