[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.
signature.asc
Description: This is a digitally signed message part.
- Re: GSoC project: new graphics backend, (continued)
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/29
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/29
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/29
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/29
- Re: GSoC project: new graphics backend,
Arseniy Lartsev <=
- Re: GSoC project: new graphics backend, Przemek Klosowski, 2009/03/30
Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/22
Re: GSoC project: new graphics backend, Jonathan Stickel, 2009/03/26