Is my 2D rasterizer too slow?

[blahblahblahh]

[quote]That would be a very silly optimisation indeed.
[/quote]
Why?

[princec]

There is no possible way that checking that a bunch of dots sent down a pipeline is in fact a line without totally buggering the pipeline. Try it from a client/server OpenGL point of view, you’ll see what I mean. The server is in charge of drawing but it can’t know from one minute to the next what the client is going to send to it. And the bottleneck is the bus between them, not the drawing.

Cas

[blahblahblahh]

[quote]There is no possible way that checking that a bunch of dots sent down a pipeline is in fact a line without totally buggering the pipeline. Try it from a client/server OpenGL point of view, you’ll see what I mean. The server is in charge of drawing but it can’t know from one minute to the next what the client is going to send to it. And the bottleneck is the bus between them, not the drawing.

Cas
[/quote]
From a C/S POV you typically would put a post-processor on the client side which checks successive requests and does whatever batching/compression it can (like Nagle’ing, for instance).

/me trying to find original sources in bookmarks; failed; trying to find stuff on google…

http://weblogs.java.net/blog/chet/archive/2004/09/tiger_on_the_de_1.html

There were fixes in some rendering niches that are worth mentioning:

*

  Primitive batching on Windows: we are smarter now about how we batch up line rendering calls when using our Direct3D renderer on Windows. This reduced the (significant) overhead per line and got us up to a 10x improvement in micro benchmarks (your mileage will vary; the biggest improvement will be seen when you issue all line calls together, not interspersed with other types of rendering operations).

http://java.sun.com/j2se/1.3/docs/guide/2d/spec/j2d-awt.fm2.html

Batch Processing 

To streamline the processing of pixels, the Java 2D API processes them in batches. A batch can be either a contiguous set of pixels on a given scanline or a block of pixels. This batch processing is done in two steps:

   1. The Paint object's createContext method is called to create a PaintContext. The PaintContext stores the contextual information about the current rendering operation and the information necessary to generate the colors. The createContext method is passed the bounding boxes of the graphics object being filled in user space and in device space, the ColorModel in which the colors should be generated, and the transform used to map user space into device space. The ColorModel is treated as a hint because not all Paint objects can support an arbitrary ColorModel. (For more information about ColorModels, see "Color".")
   2. The getColorModel method is called to get the ColorModel of the generated paint color from the PaintContext.

The getRaster method is then called repeatedly to get the Raster that contains the actual color data for each batch. This information is passed to the next stage in the rendering pipeline, which draws the generated color using the cu rrent Composite object.

Still not found the original doc(s) where I read about it (it would hepl if I could remember what it/they were, but I can only say “i’ll recognise them when I see 'em”).

[princec]

It’s no wonder the API’s so bloody slow, unreliable and complicated.

Cas