1
0
Fork 0
Commit graph

12 commits

Author SHA1 Message Date
Emmanuele Bassi
266c1d7705 docs: Fix typo in the <structname> tag 2012-04-30 17:45:01 +01:00
Emmanuele Bassi
0dd74ca3fb docs: Annotation fixes
The introspection scanner has become slightly more annoying, in the hope
that people start fixing their annotations. As it turns out, it was the
right move.
2012-04-30 17:17:41 +01:00
Emmanuele Bassi
1df14c1bac Debugging cleanups
Add some more debugging notes to the layout and paint node output.
2012-03-16 16:16:40 +00:00
Emmanuele Bassi
ae554a5061 Rename 'bilinear' scaling filter to 'trilinear'
Yes, it's not really the proper GL name for a linear-on-every-axis of a
texture plus linear-between-mipmap-levels minification filter, but it
has three redeeming qualities as a name:

  - LINEAR_MIPMAP_LINEAR sucks, as it introduces GL concepts like
    mipmaps in the API naming, while we're trying to avoid that;
  - people using GL already know what 'trilinear' means in this context
    without going all Khronos on their asses;
  - we're using 2D textures anyway, so 'linear on two axes and linear
    between mipmap levels' can be effectively approximated to
    'trilinear'.

I mean, if even the OpenGL official wiki says:

  Unfortunately, what most people think of as "trilinear" is not linear
  filtering of a 3D texture, but what in OpenGL terms is GL_LINEAR mag
  filter and GL_LINEAR_MIPMAP_LINEAR in the min filter in a 2D texture.
  That is, it is bilinear filtering of each appropriate mipmap level,
  and doing a third linear filter between the adjacent mipmap levels.
  Hence the term "trilinear".
                -- http://www.opengl.org/wiki/Texture

then the horse has already been flogged to death, and I don't intend to
be accused of necrophilia and sadism by flogging it some more.

Prior art: every single GL tutorial in the history of ever;
CoreAnimation's scaling filter enumerations.

If people want to start using 1D or 3D textures they they are probably
going to be using Cogl API directly, and that has the GL naming scheme
for minification and magnification filters anyway.
2012-03-16 12:33:40 +00:00
Emmanuele Bassi
8904f7cbe4 paint-nodes: Make part of the API internal
At least for the time being, we only expose the parts of the API that we
want to use internally and for new, out-of-tree Content implementations.

The full PaintNode tree API will be made public in 1.12 once we branch
master.
2012-03-16 12:33:40 +00:00
Emmanuele Bassi
5432775eff paint-node: Make texture template pipeline clamp to edge
It's safer, and consistent with the rest of Clutter, to make sure that
the template pipeline we use for ClutterTextureNode has its wrap mode
set to clamp-to-edge.
2012-03-16 12:33:39 +00:00
Emmanuele Bassi
fb106ece05 Use the content scaling filters
Both ClutterCanvas and ClutterImage should use the minification and
magnification filters set on the actor, just like the use the content
box and the paint opacity.
2012-03-16 12:33:38 +00:00
Emmanuele Bassi
e2f1153c46 paint-node: Remove redundant declarations 2012-03-16 12:33:37 +00:00
Emmanuele Bassi
a58be8aad1 paint-nodes: Fix compiler warning 2012-03-16 12:33:36 +00:00
Emmanuele Bassi
51cca132e0 paint-nodes: Use logical extents for the TextNode::draw
When we decide if we ought to clip, we should use the logical extents of
the PangoLayout, just like we do for ClutterText.
2012-03-16 12:33:36 +00:00
Emmanuele Bassi
f4d8fb054a paint-node: Use JSON-GLib for debug serialization
Instead of our homegrown string building; this at least ensures that
we're generating proper data, instead of random strings. Plus, using
JsonNode and JsonBuilder, we can ask the PaintNode subclasses to
serialize themselves in a sensible way.
2012-03-16 12:33:36 +00:00
Emmanuele Bassi
b83dc6abfa Add PaintNode, an element on the render object tree
Now that we have a proper scene graph API, we should split out the
rendering part from the logical and event handling part.

ClutterPaintNode is a lightweight fundamental type that encodes only the
paint operations: pipeline state and geometry. At its most simple, is a
way to structure setting up the programmable pipeline using a
CoglPipeline, and submitting Cogl primitives. The important take away
from this API is that you are not allowed to call Cogl API like
cogl_set_source() or cogl_primitive_draw() directly.

The interesting approach to this is that, in the future, we should be
able to move to a purely retained mode: we will decide which actors need
to be painted, they will update their own branch of the render graph,
and we'll take the render graph and build all the rendering commands
from that.

For the 1.x API, we will have to maintain invariants and the existing
behaviour, but as soon as we can break API, the old paint signal will
just go away, and Actors will only be allowed to manipulate the render
tree.
2012-03-16 12:33:35 +00:00