[ENet-discuss] CPU Usage

[Lee Salzman]

I apologize in advance for being blunt, but if you are sending 1 pixel 
per packet, and sending entire 800x600 pixel frames this way (one pixel 
at a time), I am speechless. Seriously, do not do that, ever, never 
ever, never ever ever. You should be sending the entire framebuffer in 
one packet if you need to send each frame reliably, or if you can afford 
lossiness, in unreliable 1KBish screen tiles even better. You should 
also be not using up more than 3 bytes per pixel, and where possible 
compressing that to less - though ENet's built-in PPM compression will 
actually help there.

Lee

On 09/26/2010 04:30 PM, Nicholas J Ingrassellino wrote:
> I am running a little experiment in C++ using ENet v1.3.0 with MSVC 
> 2k8. What I am attempting to create is a pure dumb terminal-style 
> application where all video is done on a remote server and sent to the 
> client while the client only sends over key presses. Yes, yes, I know; 
> I am reinventing the wheel and half the people reading this do not 
> approve. It is just an experiment I am doing for kicks.
>
> My issue lies in ENet's CPU usage. I had noticed that during the 
> receiving/drawing step my client CPU usage went to 100% and was 
> reacting way too slow to do what I want to do. After a while I have 
> narrowed the problem down to ENet. I even went as far as taking ENet 
> out of the picture to be sure it was not something else using 
> simulated data as if it were received from the server (IE virtually 
> not changing my client main loop). Just so I have gone on the record 
> as saying it the client, once ENet is removed from the picture, can 
> draw an image, pixel by pixel, 60 times a second without breaking a sweat.
>
> My server is sending 7 bytes (payload, of course) for each pixel. At 
> 800x600x24 I am aware this is a hell of a lot of data but it is still 
> eating a lot more CPU than I figured it would on the client. The 
> server gets all the data off in a timely fashion but the receiving 
> side can not get it nearly as fast as it was sent so it ends up 
> backing up really quickly. The client code looks like this:
>
>     while ( !main_loop_exit ) {
>         acquire_screen();
>         blit(buffer, screen, 0, 0, 0, 0, buffer->w, buffer->h);
>         release_screen();
>
>         if ( keypressed() ) {
>             unsigned char key_next = readkey() & 0xff;
>             ENetPacket *packet = enet_packet_create(&key_next,
>     sizeof(unsigned char), ENET_PACKET_FLAG_RELIABLE);
>             enet_peer_send(peer, 0, packet);
>         }
>
>         if ( enet_host_service(client, &event, 0) > 0 ) {
>             if ( event.type == ENET_EVENT_TYPE_RECEIVE ) {
>                 _putpixel24(buffer, ((PACKET_PAYLOAD
>     *)event.packet->data)->x, ((PACKET_PAYLOAD
>     *)event.packet->data)->y, makecol(((PACKET_PAYLOAD
>     *)event.packet->data)->r, ((PACKET_PAYLOAD
>     *)event.packet->data)->g, ((PACKET_PAYLOAD
>     *)event.packet->data)->b));
>                 enet_packet_destroy(event.packet);
>             }
>             else if ( event.type == ENET_EVENT_TYPE_DISCONNECT )
>                 main_loop_exit = true;
>         }
>         else
>             rest(1);
>     }
>
>
> Any input on how I can speed up ENet's processing of packets would be 
> greatly appreciated. I think ENet is a perfect fit for this project on 
> paper if I can just figure out how to make it sing.
>
> ------------------------------------------------------------------------
>
> Nicholas J Ingrassellino
> LifebloodNetworks.com <http://www.lifebloodnetworks.com/> || 
> nick at lifebloodnetworks.com <mailto:nick at lifebloodnetworks.com>
>
> "The idea that I can be presented with a problem, set out to logically 
> solve it with the tools at hand, and wind up with a program that could 
> not be legally used because someone else followed the same logical 
> steps some years ago and filed for a patent on it is horrifying."
> - John Carmack on software patents
>
>
> _
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100926/ec26760e/attachment.html>