Hhissssssss! (GDI+)
Feb. 13th, 2006 01:30 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
talarubiSo some time ago, Microsoft came up with a nice new OO graphics API known as GDI+. While basic, it's a great first step and has essential things like transparency, antialiasing, gradients, image loaders, and a crapload of ways to shuffle data around without excess fussing (GDI+ on a DirectDraw surface? Sure!). It's just generally so much cleaner. There's no more confusing handle selection, and in C++ you can just have local objects on the stack. Very neat.
So naturally I spent a few hours playing around. To my great horror, I find:
1) This is a software engine (no acceleration like the crufty old GDI has).
2) It's doing a bitmap copy or two for, e.g. every
3) I can watch this happen!!*
4) Resizing the window is slower--recreating
Bwauuuugh! Okay, I get why the compositing is molasses, it's a read/write op, which quickly goes to Video Hell. But I turned that off and it still hardly qualifies as fast.**
Double-buffering, of course, fixes it. For the most part. If my bitmap format matches the screen. But thing is, most office-type apps don't need double-buffering. What they need is fast lines, boxes, text and scrolling (aka big, fast video-side copies)... all inside a fullscreen window, worst-case. Buffering doesn't provide that; AGP is barely fast enough without two or three layers of abstraction in the way. IMHO, that's the biggest reason Java and other "modern" apps feel so slow. If you're running a PCI-E board I bet it's great, but for me, it just lacks the crisp response I associate with native code.
Yeah, yeah, I know... some will say, what's he spewing about, he should buy new hardware! To which I reply, mine works fine, it doesn't need to be in a landfill, and by the way, would they like to donate? :P Ah hell, I really am rambling now. G'nightxx0rs y'all.
* Cue nostalgia regarding my QBASIC days, which has, I realise, now faded. SCREEN 13, baby!
**disablesneuters antialiasing. And I'm using a Delphi wrapper, not C++. Maybe I'm doing something wrong, I dunno. But clearly
So naturally I spent a few hours playing around. To my great horror, I find:
1) This is a software engine (no acceleration like the crufty old GDI has).
2) It's doing a bitmap copy or two for, e.g. every
DrawLine thrown at the screen!3) I can watch this happen!!*
4) Resizing the window is slower--recreating
Bitmap and Graphics objects incurs visible delays!?Bwauuuugh! Okay, I get why the compositing is molasses, it's a read/write op, which quickly goes to Video Hell. But I turned that off and it still hardly qualifies as fast.**
Double-buffering, of course, fixes it. For the most part. If my bitmap format matches the screen. But thing is, most office-type apps don't need double-buffering. What they need is fast lines, boxes, text and scrolling (aka big, fast video-side copies)... all inside a fullscreen window, worst-case. Buffering doesn't provide that; AGP is barely fast enough without two or three layers of abstraction in the way. IMHO, that's the biggest reason Java and other "modern" apps feel so slow. If you're running a PCI-E board I bet it's great, but for me, it just lacks the crisp response I associate with native code.
Yeah, yeah, I know... some will say, what's he spewing about, he should buy new hardware! To which I reply, mine works fine, it doesn't need to be in a landfill, and by the way, would they like to donate? :P Ah hell, I really am rambling now. G'nightxx0rs y'all.
* Cue nostalgia regarding my QBASIC days, which has, I realise, now faded. SCREEN 13, baby!
**
CompositingModeSourceCopy also DrawLine et al is not CPU-bound, it's just the copies. Google suggests others are running into this too. :(