Results 1 to 3 of 3

Thread: webcam frames as CL_Sprite ... problem :(

  1. #1

    Question webcam frames as CL_Sprite ... problem :(

    Hi all...

    I'm a new Italian entry of the marvellous cLanLib (sorry for my goofy english ...).

    I'm trying to acquire from a webcam and put the result into a Sprite... to evaluate some collision on it.... but I have problem to show the CL_Sprite created...

    and now ... some code....
    Code:
    CL_GraphicContext *		m_renderWindow;
    
    CL_Sprite	*		m_cl_sprite;
    CL_SpriteDescription		m_cl_sprite_desc;
    CL_PixelBuffer	*		m_cl_img;
    
    //camera's buffer image
    unsigned char * 		m_pBuffer;
    unsigned char * 		m_tmpBuffer;
    unsigned int *			m_ui_pBuffer;
    
    
    void Camera::init()
    {
    	//create the buffer unsigned char that will contain the entire camera frame
    	m_pBuffer = new unsigned char[m_dimension];
    	m_tmpBuffer = new unsigned char[m_dimension];
    
    	//trick used to fill the buffer in a cLanLib's right way, if not considered like a unsigned integer
    	//when the clanlib do the drawPixel a wrong format is used...the result... a red predominant image...
    	m_ui_pBuffer = (unsigned int *)m_pBuffer;
    
    
    	m_cl_img = new CL_PixelBuffer(m_width, m_height,cl_rgba8,m_ui_pBuffer,true);
    	
    
    	m_cl_sprite_desc.add_frame();
    
    
    	m_cl_sprite = new CL_Sprite(*m_renderWindow, m_cl_sprite_desc);
    
    }	
    
    
    
    void Camera::compute( bool p_withEffects )
    {
    
    	if( !CameraGetFrame( m_pCam, m_tmpBuffer ) )
    		return;
    
    	//todo ... maybe better in openCV 
    	// from BGRA to RGBA
    
    	//trick used to fill the buffer in a cLanLib's right way, if not considered like a unsigned integer
    	//when the clanlib do the drawPixel a wrong format is used...the result... a red predominant image...
    	unsigned int r = 0, g = 0, b =0, a = 0;
    
    	for(int i=0; i<m_dimension  ; i+=4)
    	{
    		r = m_tmpBuffer[i+2];
    		g = m_tmpBuffer[i+1];
    		b = m_tmpBuffer[i+0];
    		a = 0XFF;
    
    		m_ui_pBuffer[i / m_numChannels] = (r << 24) + (g << 16) + (b << 8) + a;
    	}
    
    }
    
    void Camera::draw()
    {
    
    	//this one draw black
    	m_cl_sprite->draw(*m_renderWindow,0,0); 
    
    
    	//this one draw correctly the frame but very slow with a memory leak	
    	// CL_Sprite* test = new CL_Sprite(*m_renderWindow,m_cl_sprite_desc);
    	// test->draw(*m_renderWindow,0,0);
    	// delete test;
    	
    
    // CL_Rect * rect = new CL_Rect(0, 0, m_renderWindow->get_width(),m_renderWindow->get_height());
    	//this one draw fast "camera's fps" again with mem leak
    	// m_renderWindow->draw_pixels(
    	// 	(float) m_renderWindow->get_width() - m_cl_sprite->get_width(),
    	//	(float) m_renderWindow->get_height()- m_cl_sprite->get_height(),
    	//	*m_cl_img, *rect );
    
           //delete rect;
    }


    So... in the draw method will start the problem....the CL_Pixelbuffer is correctly filled, with a gc.draw_pixel() the right frame is shown... but with a mem leak... in a few sec ram growup increasily...

    noway to do a m_cl_sprite->draw(*m_renderWindow,0,0); black result...

    ok to istantiate a sprite in the draw cicle but very slow & mem leak also there...

    any suggestion ???

    tnx very much...

  2. #2

    Default come on...

    Come on... no suggestion for me ???

    whic class may I debug to find the problem ???

  3. #3

    Default

    Alright, now I'm not to fimiliar with ClanLib itself, so take everything I say with a large grain of salt...

    That said I'm curious as to what you do in CameraGetFrame(), as it is a black box function at the moment that seems like it could be causing problems.

    With regards to the slow drawing that happens when you draw correctly, I can't say that I'm surprised. Within you're render loop you are instantiating an object, (a slow operation in any language), you have to fill it with the appropriate things (takes time), then draw it, (yet more time) and then you promptly destruct it (another slow operation). First dynamically allocating and freeing takes a lot of time that you don't want to spend everytime. You'd be better off with one sprite that you reused everytime you draw rather then dynamically allocating one everytime. Furthermore you are dynamically allocating a piece of memory that you only use within a local context, you might as well just create the sprite on the stack, and let the function clean it up automatically (which will be much faster as the stack can just be dropped in one move to delete the sprite, and better still as it will be handled automatically).

    Basically as a CS person I can tell you that this creation and deletion of a object everytime you render will take time. (And if there is a leak within that scope then it's unsurprising you leak memory). Although a note, if you're checking memory leaks with valgrind while running, everything will be slow and take a lot of time, regardless of what you do

    Hopefully that was helpful and feel free to correct me if I went wrong or off the deep end somewhere...

Similar Threads

  1. Memory management of CL_Sprite
    By kuroyan in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 04-15-2010, 08:39 AM
  2. Possible Bug? Scaling and clipped frames.
    By catch22 in forum Official ClanLib SDK Forums
    Replies: 14
    Last Post: 06-11-2009, 12:25 PM
  3. CL_Sprite mouse cursor
    By AlfaRed in forum Official ClanLib SDK Forums
    Replies: 2
    Last Post: 02-11-2009, 09:29 AM
  4. cl_sprite with multiple frames
    By dwune in forum Official ClanLib SDK Forums
    Replies: 7
    Last Post: 08-29-2008, 08:49 AM
  5. CL_Sprite problems
    By gmatt in forum Official ClanLib SDK Forums
    Replies: 0
    Last Post: 06-29-2007, 05:38 PM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •