About Direct2D


#1

Hi Jules,

I know you plan to support Direct2D, which is a REALLY nice thing. However, do you know that Direct2D will be only availble to user who have at least, Windows Vista ?
What is gonna happen if the user has WindowsXP ?

  • The program won’t run ?
  • It will fallback to GDI ?

It would be nice if we could optionally use DirectDraw ad well. According to end of 2010 figures, 40% of windows computers still run XP


#2

Yes, I know: if Direct2D isn’t available, it’ll just do exactly what it does now.

DirectDraw isn’t the same thing at all - all it does is blit images around, it can’t actually do any 2D drawing, so isn’t something you could use to write a rendering engine (otherwise I’d have done so years ago).


#3

Yes DirectDraw doesn’t do much fancy stuff, but for raw blitting, it’s way faster than GDI, isn’t it ?
Anyway, what’s the recomended option, if you want to keep compatibility with XP, and not spend too much processing time for drawing things fast on the screen (stuff like VU/level-meters for example) ?


#4

Don’t optimize without profiling first.

GDI bitblt is faster than DDraw bliting from CPU memory to GPU memory.
Anyway, in a rendering chain, the blitting duration is very very very very low compared to the thousands of operations filling the bitmap first, so even if it wasn’t the case, the blitting is clearly not the place to optimize at first.


#5

It’s even worse : I’m optimizing before writing the code :lol:

More seriously, my point here, is not that Juce should use direct draw, it’s more because I read about some people having graphics performance issues on the forum, and I’m wondering about the “right way” to do it, from the start.


#6

I think the only person who’s talking about graphics performance is TheVinn, and I have some doubts about his sanity… Best not to worry about it :wink:


#7

Bah, you know, graphics performance is like the last number on your bank’s report. You always want more, but you don’t support the pain required to do so.


#8

I love you too :stuck_out_tongue:


#9

I think the only person who’s talking about graphics performance is TheVinn, and I have some doubts about his sanity… Best not to worry about it :wink:[/quote]

I don’t know if there are many C++ coders out there whose sanity is not questionable :smiley:
But I’ll take your advice and not worry about it ! :slight_smile:


#10

Utter bs, sorry. On my system with Win7, blitting takes far more time the rendering. If I do only a fillRect() in a Component, the blitting will take about 2x more time. With desktop composition active, it’s even worse. Transferring data from a bitmap to the GPU takes time. And if you do it at high rates, above 50Hz, for let’s say 60 level meters on screen, it takes even more time. I remember that BitBlt was much faster on XP, with a far less powerful machine.


#11

Utter bs, sorry. On my system with Win7, blitting takes far more time the rendering. If I do only a fillRect() in a Component, the blitting will take about 2x more time. With desktop composition active, it’s even worse. Transferring data from a bitmap to the GPU takes time. And if you do it at high rates, above 50Hz, for let’s say 60 level meters on screen, it takes even more time. I remember that BitBlt was much faster on XP, with a far less powerful machine.[/quote]

Zamrate, the other day, I read the thread about your rendering speed problems. Correct me if I’m wrong but it seems that the function taking loads of time was PixelARGB::blend, isn’t it ?

Well if that’s the case, it doesn’t contradict X-Ryl669 post, because PixelARGB::blend is much more complex than a simple blitting . Blitting is just setting a value, and can be done by blocks while PixelARGB::blend has to read the current pixel value, blend it with the current value, and write the new value…

I have the same kind of problems but didn’t really investigate so I might be totally wrong :slight_smile:

My 2 cents …


#12

I pointed out that blend() was at the top of his profile but he brushed me aside.


#13

I pointed out that blend() was at the top of his profile but he brushed me aside.[/quote]

Good old forum wars ! It’s been a while :smiley:


#14

A profile of well optimized code which uses the software renderer should show the final “BitBlt()” to the screen as taking up the most time, this implies that you’re getting the highest frame rate.


#15

A profile of well optimized code which uses the software renderer should show the final “BitBlt()” to the screen as taking up the most time, this implies that you’re getting the highest frame rate.[/quote]

Amen to that