Nicolas Alvarez wrote:
> Mike Raiford wrote:
>> 1024x768 frame buffer...
> 
> I estimate I'm getting 0.5fps.

Wow... are you running Vista, by any chance..? On my WinXP machine, I 
was getting about 20fps..

I found that on my Vista machine it runs significantly slower.

Post a reply to this message

Darren New wrote:
> Mike Raiford wrote:
> 
> OK. I'm just saying ... what makes you think it's not "down to the wire" 
> in this case?  It doesn't look like you're doing anything in the inner 
> loops of the tick that you couldn't do equally well in C, so why 
> wouldn't the JIT generate equivalently efficient code?
> 

Maybe it is, but everything is still managed code. The JIT should 
produce efficient code, for sure, and it does. I was just happy to see 
that an effect like this can be achieved, and with a relatively large 
frame buffer. That's all I guess. Some seem to think that the .NET 
framework, or that JIT environments are too slow for these sorts of 
tricks, or effects.

I think, didn't someone port Quake to Managed C++?

> 
> Cool. I've only done large-scale manipulations, not drawing 
> pixel-by-pixel, so I guess I never ran into that problem.
> 

Right, the GDI+ functions are generally pretty good for most drawing 
situations.

Post a reply to this message

Mike Raiford wrote:
> Maybe it is, but everything is still managed code. The JIT should 
> produce efficient code, for sure, and it does. I was just happy to see 
> that an effect like this can be achieved, and with a relatively large 
> frame buffer. That's all I guess. Some seem to think that the .NET 
> framework, or that JIT environments are too slow for these sorts of 
> tricks, or effects.

True. People who never really think about the issues tend to just listen to 
the FUD.

> I think, didn't someone port Quake to Managed C++?

Yes, but I'm not sure they ported the "hard parts". As in, it was something 
like a few hundred lines of code written over the course of a handful of 
hours to "port" it. I don't think they (for example) moved all the data 
structures into managed space, other than perhaps the screen and keyboard I/O.

> Right, the GDI+ functions are generally pretty good for most drawing 
> situations.

I thought the transformation matrix approach to color control was pretty 
cool. Probably pretty common across toolkits, I'd guess, tho.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

> I found that on my Vista machine it runs significantly slower.

Running Vista here, I estimate about 10-20 fps (assuming it goes up one line 
per frame).

It's only using 1 of my cores though .... :-)

Post a reply to this message

> I would think there's relatively little need to be slow in a program like 
> this, where it's all manipulation of fundamental structures. 

I think the GPU would be faster at this sort of program than the CPU :-)

Post a reply to this message

scott wrote:
>> I found that on my Vista machine it runs significantly slower.
> 
> Running Vista here, I estimate about 10-20 fps (assuming it goes up one 
> line per frame).

Then why the hell is my Vista box always so freaking slow?!!

> It's only using 1 of my cores though .... :-)
> 
> 

Yeah, I didn't get all fancy and multi-threaded.. I suppose it could be 
easily parallelized, though.

Post a reply to this message

>> Running Vista here, I estimate about 10-20 fps (assuming it goes up one 
>> line per frame).
>
> Then why the hell is my Vista box always so freaking slow?!!

Ooh I just tried it on my XP laptop, and by the time the red has got to the 
top it's only 80% of the way there on Vista.  My Vista box is about 10x 
faster than my laptop so who knows what is going on.

Does it make a difference under Vista if you take out the 
"ControlStyles.OptimizedDoubleBuffer" flag?

Also you are locking the bitmap for quite a long time (relatively), you 
should literally lock, memcopy, unlock. Any processing should be done 
outside of that on a separate buffer.  Maybe it is holding up Vista somehow 
when it's trying to copy the bitmap to the graphics card?

Post a reply to this message

scott wrote:
>> I would think there's relatively little need to be slow in a program 
>> like this, where it's all manipulation of fundamental structures. 
> 
> I think the GPU would be faster at this sort of program than the CPU :-)

http://www.nzone.com/object/nzone_cascades_videos.html

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Mike Raiford wrote:
> Wow... are you running Vista, by any chance..? On my WinXP machine, I
> was getting about 20fps..

I'm running it via Mono, on Linux.

Post a reply to this message

Darren New wrote:

> http://www.nzone.com/object/nzone_cascades_videos.html

I'm *still* irritated that you can't run Cascades without Vista...

Post a reply to this message