#WM_PAINT

[kawaoneechan]

I have to wonder.

How hard is it to draw a single pixel in... let's say OpenGL? How many lines would it take? Let's assume that all the boilerplating to get an OpenGL viewport on screen in <OS NAME HERE> is already covered.

I asked this in Discord and the one guy who bothered to reply could not answer.

Mostly because modern OpenGL is a 3D rasterization system.

In raw Win32? Assuming the boilerplating includes a window procedure and you're doing it the moment the window contents need a redrawing, you'd add a case for WM_PAINT, then call BeginPaint, SetPixel, EndPaint. Four lines.

In DOS it's just insultingly simple, especially in Mode 0x13. You just straight-up poke the video memory directly. VRAM[(y * 320) + x] = color, boom you're done. It's not the most efficient method, considering "* 320" is not nice, but it's one line.

[codebred]

This is, really and truly, exactly how Windows used to be programmed all the way through at least Windows 7, and many modern Windows programs still work this way under the hood. Views would be drawn whenever asked via a WM_PAINT message. To be fast, WM_PAINT messages generally only used state stored locally in the view, and to keep them repeatable, they were forbidden from manipulating state. Because painting was separated from state changes, Windows could redraw only the part of the screen that actually needed to be redrawn. Each view had a function associated with it, called its WndProc, that took four parameters: the actual view getting updated; uMsg, which was the message type as an integer; and two parameters called wParam and lParam that contained data specific to the message. The WndProc would update any data stores in response to that message (frequently by sending off additional application-specific messages), and then, if applicable, the data stores could mark the relevant part of the screen as invalid, triggering a new paint cycle. Finally, for programmer sanity, you can combine lots of views inside other views. Virtually every widget you see in Windows — every list, every checkbox, every button, every menu — is actually its own little reusable view, each with its own little WndProc and its own messages.This is exactly what Flux does. You can see this design very clearly in the official Flux repository’s example app. We can see the messages getting defined as an enum, just like you’d do in old-school Windows programming. We can see the giant switch statement over all the messages, and note that different data is extracted based on the message’s actionType. And, of course, you can see components rendering idempotently based off their small amount of internal state.