Darren New 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. As in, 
> I would think the speed of a program like this in .NET wouldn't 
> necessarily be any slower than a similar program in plain C, unless the 
> JIT is just really bad.

But, that's sort of my point. :) You don't need to be down to the wire 
to get fast performance out of the system.

> Was there really any reason to use the unsafe pointers?
> 

There was. There are 2 ways to access the bitmap data. One by using the 
setpixel and getpixel functions. This is very slow. essentially every 
access to the pixel data requires a conversion to and from a color 
structure.

The other way is to access the buffer directly, hence the unsafe pointers.

Post a reply to this message

Mike Raiford wrote:
> Darren New 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. As 
>> in, I would think the speed of a program like this in .NET wouldn't 
>> necessarily be any slower than a similar program in plain C, unless 
>> the JIT is just really bad.
> 
> But, that's sort of my point. :) You don't need to be down to the wire 
> to get fast performance out of the system.

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?

> There was. There are 2 ways to access the bitmap data. One by using the 
> setpixel and getpixel functions. This is very slow. essentially every 
> access to the pixel data requires a conversion to and from a color 
> structure.

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

-- 
   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:
> 1024x768 frame buffer...

I estimate I'm getting 0.5fps.

Post a reply to this message

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