@kas1e I recall hearing that the way that OWB uses Cairo counter-acts the benefits of the hardware acceleration. Basically, it ends up copying bitmaps between RAM and VRAM so often that it is faster to render it all in software and then copy it to VRAM once. I cannot remember the details as to why but, from memory, it wasn't something that was easily fixed. @alfkil The graphics.library isn't very good at rounded edges to rectangular shapes. The outline can be done using Move() and Draw() (you'll have to approximate the rounded edges with line segments). For the fill, you might be able to use AreaMove(), AreaDraw(), and AreaEnd() to do the fill, but I'm not sure how HW accelerated that would be. If you used RectFill() for the bulk of the fill, it might not matter too much. Alternatively, create a small bitmap with the desired fill colour, and use CompositeTags() with a vertex array to do the fill. The small bitmap would be the source "texture." IMPORTANT: There is no software fallback for CompositeTags() with vertex arrays for graphics cards that don't support it. You will have to check for a failure (set the HW only flag to be on the safe side), and provide your own backup rendering routine. Hans

@alfkil Try adding: COMPTAG_OffsetX, x, COMPTAG_OffsetY, y, If you read the documentation carefully, you'll discover that COMPTAG_DestX, COMPTAG_DestY, COMPTAG_DestWidth, and COMPTAG_DestHeight set a clipping rectangle in the destination bitmap. Those tags do NOT set the offset to where rendering will take place. You need to set COMPTAG_OffsetX, and COMPTAG_OffsetY to set where to render to. You don't even need to set the clipping rectangle, as it will default to the whole destination bitmap. COMPTAG_DestX, COMPTAG_DestY, COMPTAG_DestWidth, and COMPTAG_DestHeight are more useful when you're rendering vertex arrays and want the result to be clipped to a specific region. Hans