scatter with dots?

Hi matplot-list, drawing scatterplots with thousends of

    > scatter dots (marker='o') yields in bloated file sizes for
    > vector-formats (ps, svg). The reason for that is, that each
    > marker circle ist made of a large number of lines instead of
    > a simple arc (0..360 degree) i.e.

    > Can this be patched easily? and btw what is the meaning of
    > the _newstyle attribute in the drawing methods?

Originally the backends drew each marker with a separate function
call, which was slow and prevented optimizations. We introduced a new
API to make marker drawing fast, but rather than break all the
noncompliant backends we left a flag in for newstyle, meaning the new
API, to determine which method to use. Unfortunately, this supported
laziness, and no backends other than *Agg support the new method
(which can be 25x faster...) It would also enable you to introduce
these optimizations, eg postscript macros, if you added it to PS.
Search the dev archives for newstyle for length discussions. I'll be
happy to advise further if you are interested in pursuing this.

JDH

I think the draw_markers function already exists for ps, I wrote it up a while
back, but we ended up masking it when problems arose in the new API.

Darren

···

On Wednesday 30 November 2005 16:18, John Hunter wrote:

    > Hi matplot-list, drawing scatterplots with thousends of
    > scatter dots (marker='o') yields in bloated file sizes for
    > vector-formats (ps, svg). The reason for that is, that each
    > marker circle ist made of a large number of lines instead of
    > a simple arc (0..360 degree) i.e.

    > Can this be patched easily? and btw what is the meaning of
    > the _newstyle attribute in the drawing methods?

Originally the backends drew each marker with a separate function
call, which was slow and prevented optimizations. We introduced a new
API to make marker drawing fast, but rather than break all the
noncompliant backends we left a flag in for newstyle, meaning the new
API, to determine which method to use. Unfortunately, this supported
laziness, and no backends other than *Agg support the new method
(which can be 25x faster...) It would also enable you to introduce
these optimizations, eg postscript macros, if you added it to PS.
Search the dev archives for newstyle for length discussions. I'll be
happy to advise further if you are interested in pursuing this.