Results 1 to 7 of 7

Thread: Why not pass GraphicContext by reference?

  1. #1
    Peasant
    Join Date
    Feb 2009
    Posts
    7

    Default Why not pass GraphicContext by reference?

    Hello everyone,

    I've been working on ClanLib for sometime now and it's a wonderful library, I want to develop a game framework and use it to develop my indie games.
    The switch from 0.8 to 2.0 did not hurt me much, beside resource management, you see I have implemented a multi-threaded resource loading system, with progress signal and everything, and that wasn't a trivial task at all, OpenGL is not friendly when it comes to multithreading (not ClanLib's fault )

    The second difference that disturbed me was that many methods need the GraphicContext to be passed to them by value in 2.0, and it is not optional, you must pass the object even if you want to draw a mere point to screen.
    As I understand, passing objects by value has a certain overhead, I checked the CL_GraphicContext class members, and it has only a shared pointer of the GC impl, so I presume passing the object would increment the ref count.

    But why is that desired? and what's wrong with passing by reference? perhaps I'm not using it the right way?

    I also have a minor issue with the latest SVN release, the Sound component gives compile errors (Using VS2005Pro, and static release with unicode), sample:

    Just wanted to point it out in case no one already did.

    Update: Don't mind that, my build was corrupted for some reason, building from a fresh SVN checkout fixed the issue.
    Last edited by SandHawk; 06-22-2009 at 02:18 PM. Reason: Build revelations ;)

  2. #2
    Master Sorcerer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    ClanLib does pass CL_GraphicContext by reference almost everywhere, exactly for the reason you point out: performance. Where is it that it is not passed by reference?

    It is probably a bug in the API if it could been passed by reference and should be corrected.

    Thanks for the kind words about the library

  3. #3
    Peasant
    Join Date
    Feb 2009
    Posts
    7

    Default

    Thank you for replying.
    I shall provide a few examples pulled directly out of ClanLib2 source to support my claims

    from CL_Draw, drawing anything requires GC passed by value:
    Code:
    class CL_API_DISPLAY CL_Draw
    {
    public:
    	static void point(CL_GraphicContext gc, float x1, float y1, const CL_Colorf &color);
    	static void point(CL_GraphicContext gc, const CL_Pointf &point, const CL_Colorf &color);
    ...etc
    from CL_Texture, it's constructors need GC to be passed by value:

    Code:
    CL_Texture(CL_GraphicContext context, CL_TextureDimensions texture_dimensions);
    
    CL_Texture(CL_GraphicContext context, int width, int height, CL_TextureFormat internal_format = CL_RGBA);
    ...
    While CL_Image constructors need a reference to GC:
    Code:
    CL_Image(CL_GraphicContext &context, CL_Texture texture, CL_Rect rect);
    
    CL_Image(CL_GraphicContext &context, CL_Subtexture &sub_texture);
    ...
    (mind boggling)

    But... I haven't dug deep in clanlib2 code (yet), so I may be missing something?

  4. #4
    Master Sorcerer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    OK, that's an error in CL_Draw and CL_Texture. They should take a reference to a gc, just like CL_Image does.

    The reason this has gone unnoticed is because in both situations the code is not as time critical as it may seem. Creating and destroying textures are non-trivial operations that an application should keep at a minimum (like minimizing heap allocations in a time critical loop). The overhead of a reference count here is not of great importance.

    As for CL_Draw, here it is more critical, but these are all slow convenience functions that should not be used if you do it a lot. Kind of like a set_pixel() function on a pixel buffer can be used rarely but if you need to change half the pixels the performance will suck and you should apply a different method.

    For performance, the application should store the data on the GPU, using a CL_VertexArrayBuffer and then use gc.draw_primtiives to render it. The functions in CL_Draw suffer from the fact that things drawn will have to be transfered to the GPU every frame, and like a set_pixel function even such transfers are faster and more efficient if you do it in large blocks instead.

    That said, the functions in CL_Draw should of course take it by reference, since they might as well be as fast as they can be. But they will never be as fast as vertex buffers.

    The functions in CL_Draw could all be made faster by implementing a batcher for them (for CL_Draw::texture, perhaps hook it into the sprite/image batcher), but mostly we have these functions for fairly rare operations where one just quickly want to see something without bringing out the big performance artillery.

  5. #5
    Peasant
    Join Date
    Feb 2009
    Posts
    7

    Default

    Ok, I modified the source to pass GC by reference instead, I had to remove a few consts and get rid of local graphic context constructs, I avoided any severe modifications.

    I attached a patch file that includes the modifications in case someone wants to use it.
    Attached Files Attached Files

  6. #6
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Bergen, Norway
    Posts
    588

    Default

    Thanks for the huge patch! It has been applied. There was a slight problem with gui_component.h - you did include using an "API/" folder, but I've fixed that.

  7. #7
    Peasant
    Join Date
    Feb 2009
    Posts
    7

    Default

    Quote Originally Posted by sphair View Post
    Thanks for the huge patch! It has been applied. There was a slight problem with gui_component.h - you did include using an "API/" folder, but I've fixed that.
    Thanks for applying it and fixing the header issue.

Similar Threads

  1. Search feature on the scripting reference
    By Pleng in forum Novashell Game Creation System
    Replies: 5
    Last Post: 06-05-2009, 11:45 AM
  2. Minor reference error
    By mikael in forum Novashell Game Creation System
    Replies: 1
    Last Post: 07-09-2008, 11:12 PM
  3. CL_Slot undefined reference
    By karaman in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 05-30-2008, 11:00 AM
  4. Surfaces vs. GraphicContext
    By kullerhamPster in forum Official ClanLib SDK Forums
    Replies: 3
    Last Post: 03-25-2007, 07:18 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
  •