octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC project: new graphics backend


From: Arseniy Lartsev
Subject: Re: GSoC project: new graphics backend
Date: Mon, 30 Mar 2009 16:33:32 +0400
User-agent: KMail/1.10.3 (Linux/2.6.27.19-3.2-default; KDE/4.1.3; i686; ; )

On Monday 30 March 2009 01:55:29 Michael Goffioul wrote:
> I don't think this will still be in the order of a microsecond when
> rendering thousands of shaded transparent quads; the overhead
> of calling virtual functions to change the color, transparency,
> lighting for each vertex might become significant. But I agree that
> in simple cases, this won't be a problem.
If one surface contains thousand polygons, I'm going to render all those 
polygons in one virtual call.

> If I wanted to be picky, I'd say that in the above comment you're only
> talking about some more work for *you*. But in the end, you'll come with
> a quite complex interface for the abstract renderer, in order to support
> all the bits and pieces required for rendering lines, surfaces, patches...
> and support shading, lighting, transparency... (in Qt world, the interface
> would probably be similar to QPainter)
My interface is going to have higher level than QPainter. Here's how it could 
look like (copy-pasted from some old code):

void Clear();
void Plot(int n, const double *x, const double *y, const double *z,
  LineStyle lstyle, PointStyle pstyle, FillStyle fstyle,
  const PlotColor &lcolor, const PlotColor &pcolor, const PlotColor &fcolor);
void Surface(int m, int n, const double *x, const double *y, const double *z,
  const double *c, double minc, double maxc, ColoringStyle meshstyle,
  ColoringStyle surfstyle, const PlotColor &meshcolor,
  const PlotColor &fillcolor);
void SetTitle(const char *s);
void DrawGrid();
void SetAxisLabel(char axis, const char *s)
void SetColorMap(int n, const double *c);
and so forth.

>
> Yes, another renderer will probably have some similar code as the
> OpenGL renderer (there's no 1000 ways to render a line), and there's
> probably some room for code factorization (I'm especially thinking about
> the axes object, which is composed of multiple objects, like axes box,
> ticks, grid lines...). But frankly speaking, how many renderer do you think
> there will be? Maybe 2 or 3?
Exactly. Not less than 2 and not more than 3.
> Just be sure to have the best trade-off between efficiency, complexity and
> some code duplication.
Even with two renderers introducing this abstract layer could reduce total 
amount of code. It will take some effort to design it properly, but once it's 
done, things should become easier. Monolithic code is easier to write, but 
sometimes more difficult to understand.
As for efficiency loss, I think I can avoid it.

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]