isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-23 00:20:42 -05:00
Code Issues Packages Projects Releases Wiki Activity
d18b59d9e6
mutter/cogl/cogl-journal-private.h

116 lines
3.8 KiB
C
Raw Normal View History

[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2007,2008,2009 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Remove mentions of the FSF address Since using addresses that might change is something that finally the FSF acknowledge as a plausible scenario (after changing address twice), the license blurb in the source files should use the URI for getting the license in case the library did not come with it. Not that URIs cannot possibly change, but at least it's easier to set up a redirection at the same place. As a side note: this commit closes the oldes bug in Clutter's bug report tool. http://bugzilla.openedhand.com/show_bug.cgi?id=521
2010-03-01 07:56:10 -05:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
*
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
*/
#ifndef __COGL_JOURNAL_PRIVATE_H
#define __COGL_JOURNAL_PRIVATE_H
Change API so that CoglPixelBuffer no longer knows its w/h/format The idea is that CoglPixelBuffer should just be a buffer that can be used for pixel data and it has no idea about the details of any images that are stored in it. This is analogous to CoglAttributeBuffer which itself does not have any information about the attributes. When you want to use a pixel buffer you should create a CoglBitmap which points to a region of the attribute buffer and provides the extra needed information such as the width, height and format. That way it is also possible to use a single CoglPixelBuffer with multiple bitmaps. The changes that are made are: • cogl_pixel_buffer_new_with_size has been removed and in its place is cogl_bitmap_new_with_size. This will create a pixel buffer at the right size and rowstride for the given width/height/format and immediately create a single CoglBitmap to point into it. The old function had an out-parameter for the stride of the image but with the new API this should be queriable from the bitmap (although there is no function for this yet). • There is now a public cogl_pixel_buffer_new constructor. This takes a size in bytes and data pointer similarly to cogl_attribute_buffer_new. • cogl_texture_new_from_buffer has been removed. If you want to create a texture from a pixel buffer you should wrap it up in a bitmap first. There is already API to create a texture from a bitmap. This patch also does a bit of header juggling because cogl-context.h was including cogl-texture.h and cogl-framebuffer.h which were causing some circular dependencies when cogl-bitmap.h includes cogl-context.h. These weren't actually needed in cogl-context.h itself but a few other headers were relying on them being included so this adds the #includes where necessary. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 15:04:45 -05:00
#include "cogl-texture.h"
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#include "cogl-handle.h"
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
#include "cogl-clip-stack.h"
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
#define COGL_JOURNAL_VBO_POOL_SIZE 8
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
typedef struct _CoglJournal
{
CoglObject _parent;
framebuffer: Flush the journal on destruction Instead of flushing the journal whenever the current framebuffer on a context is changed it is now flushed whenever the framebuffer is about to be destroyed instead. To do this it implements a custom unref function which detects when there is going to be exactly one reference on the framebuffer and then flushes its journal. The journal now always has a reference on the framebuffer whenever it is non-empty. That means the unref will only cause a flush if the only thing keeping the framebuffer alive is the entries in the journal. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-01-24 13:16:03 -05:00
/* A pointer the framebuffer that is using this journal. This is
only valid when the journal is not empty. It *does* take a
reference on the framebuffer. Although this creates a circular
reference, the framebuffer has special code to handle the case
where the journal is the only thing holding a reference and it
will cause the journal to flush */
CoglFramebuffer *framebuffer;
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
GArray *entries;
GArray *vertices;
size_t needed_vbo_len;
cogl-journal: Use a pool of vertex arrays Previously whenever the journal is flushed a new vertex array would be created to contain the vertices. To avoid the overhead of reallocating a buffer every time, this patch makes it use a pool of 8 buffers which are cycled in turn. The buffers are never destroyed but instead the data is replaced. The journal should only ever be using one buffer at a time but we cache more than one buffer anyway in case the GL driver is internally using the buffer in which case mapping the buffer may cause it to create a new buffer anyway.
2011-06-01 09:30:45 -04:00
/* A pool of attribute buffers is used so that we can avoid repeatedly
reallocating buffers. Only one of these buffers at a time will be
used by Cogl but we keep more than one alive anyway in case the
GL driver is internally using the buffer and it would have to
allocate a new one when we start writing to it */
CoglAttributeBuffer *vbo_pool[COGL_JOURNAL_VBO_POOL_SIZE];
/* The next vbo to use from the pool. We just cycle through them in
order */
unsigned int next_vbo_in_pool;
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
int fast_read_pixel_count;
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
} CoglJournal;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* To improve batching of geometry when submitting vertices to OpenGL we
* log the texture rectangles we want to draw to a journal, so when we
* later flush the journal we aim to batch data, and gl draw calls. */
typedef struct _CoglJournalEntry
{
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *pipeline;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int n_layers;
CoglMatrix model_view;
cogl-journal: Log the clip state in the journal When adding a new entry to the journal a reference is now taken on the current clip stack. Modifying the current clip state no longer causes a journal flush. The journal flushing code now has an extra stage to compare the clip state of each entry. The comparison can simply be done by comparing the pointers. Although different clip states will still end up with multiple draw calls this at leasts allows a scene comprising of multiple different clips to be upload with one vbo. It also lays the groundwork to do certain tricks when drawing clipped rectangles such as modifying the geometry instead of setting a clip state.
2010-11-02 13:35:17 -04:00
CoglClipStack *clip_stack;
cogl-journal: Attempt to clip manually to avoid breaking up batches Before flushing the journal there is now a separate iteration that will try to determine if the matrix of the clip stack and the matrix of the rectangle in each entry are on the same plane. If they are it can completely avoid the clip stack and instead manually modify the vertex and texture coordinates to implement the clip. The has the advantage that it won't break up batching if a single clipped rectangle is used in a scene. The software clip is only used if there is no user program and no texture matrices. There is a threshold to the size of the batch where it is assumed that it is worth the cost to break up a batch and program the GPU to do the clipping. Currently this is set to 8 although this figure is plucked out of thin air. To check whether the two matrices are on the same plane it tries to determine if one of the matrices is just a simple translation of the other. In the process of this it also works out what the translation would be. These values can be used to translate the clip rectangle into the coordinate space of the rectangle to be logged. Then we can do the clip directly in the rectangle's coordinate space.
2010-11-09 14:18:37 -05:00
/* Offset into ctx->logged_vertices */
size_t array_offset;
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
/* XXX: These entries are pretty big now considering the padding in
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* CoglPipelineFlushOptions and CoglMatrix, so we might need to optimize this
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
* later. */
} CoglJournalEntry;
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
CoglJournal *
_cogl_journal_new (void);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
void
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
_cogl_journal_log_quad (CoglJournal *journal,
const float *position,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *pipeline,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
int n_layers,
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *layer0_override_texture,
cogl: Make the callback for foreach_sub_texture_in_region use const The CoglTextureSliceCallback function pointer now takes const pointers for the texture coordinates. This makes it clearer that the callback should not modify the array and therefore the backend can use the same array for both sets of coords.
2009-12-02 12:17:24 -05:00
const float *tex_coords,
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
unsigned int tex_coords_len);
cogl: remove redundant _cogl_journal_flush prototype There was a redundant _cogl_journal_flush function prototype in cogl-primitives.h
2010-02-10 13:18:30 -05:00
void
journal: Support per-framebuffer journals Instead of having a single journal per context, we now have a CoglJournal object for each CoglFramebuffer. This means we now don't have to flush the journal when switching/pushing/popping between different framebuffers so for example a Clutter scene that involves some ClutterEffect actors that transiently redirect to an FBO can still be batched. This also allows us to track state in the journal that relates to the current frame of its associated framebuffer which we'll need for our optimization for using the CPU to handle reading a single pixel back from a framebuffer when we know the whole scene is currently comprised of simple rectangles in a journal.
2011-01-06 08:25:45 -05:00
_cogl_journal_flush (CoglJournal *journal,
CoglFramebuffer *framebuffer);
cogl: remove redundant _cogl_journal_flush prototype There was a redundant _cogl_journal_flush function prototype in cogl-primitives.h
2010-02-10 13:18:30 -05:00
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
void
_cogl_journal_discard (CoglJournal *journal);
gboolean
_cogl_journal_all_entries_within_bounds (CoglJournal *journal,
float clip_x0,
float clip_y0,
float clip_x1,
float clip_y1);
gboolean
_cogl_journal_try_read_pixel (CoglJournal *journal,
int x,
int y,
Add a public cogl_framebuffer_read_pixels_into_bitmap This adds a public function to read pixels from a framebuffer into a CoglBitmap. This replaces the internal function _cogl_read_pixels_with_rowstride because a CoglBitmap contains a rowstride so it can be used for the same purpose. A CoglBitmap already has public API to make one that points to a CoglPixelBuffer so this function can be used to read pixels into a PBO. It also avoids the need to push the framebuffer on to the context's stack so it provides a function which can be used in the 2.0 API after the stack is removed. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 14:23:51 -05:00
CoglBitmap *bitmap,
cogl: Implements a software only read-pixel fast-path This adds a transparent optimization to cogl_read_pixels for when a single pixel is being read back and it happens that all the geometry of the current frame is still available in the framebuffer's associated journal. The intention is to indirectly optimize Clutter's render based picking mechanism in such a way that the 99% of cases where scenes are comprised of trivial quad primitives that can easily be intersected we can avoid the latency of kicking a GPU render and blocking for the result when we know we can calculate the result manually on the CPU probably faster than we could even kick a render. A nice property of this solution is that it maintains all the flexibility of the render based picking provided by Clutter and it can gracefully fall back to GPU rendering if actors are drawn using anything more complex than a quad for their geometry. It seems worth noting that there is a limitation to the extensibility of this approach in that it can only optimize picking a against geometry that passes through Cogl's journal which isn't something Clutter directly controls. For now though this really doesn't matter since basically all apps should end up hitting this fast-path. The current idea to address this longer term would be a pick2 vfunc for ClutterActor that can support geometry and render based input regions of actors and move this optimization up into Clutter instead. Note: currently we don't have a primitive count threshold to consider that there could be scenes with enough geometry for us to compensate for the cost of kicking a render and determine a result more efficiently by utilizing the GPU. We don't currently expect this to be common though. Note: in the future it could still be interesting to revive something like the wip/async-pbo-picking branch to provide an asynchronous read-pixels based optimization for Clutter picking in cases where more complex input regions that necessitate rendering are in use or if we do add a threshold for rendering as mentioned above.
2011-01-12 17:12:41 -05:00
gboolean *found_intersection);
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 13:21:28 -05:00
gboolean
_cogl_is_journal (void *object);
[cogl-primitives] Split the journal out from cogl-primitives.c The Journal can be considered a standalone component, so even though it's currently only used to log quads, it seems better to split it out into its own file.
2009-09-16 09:01:57 -04:00
#endif /* __COGL_JOURNAL_PRIVATE_H */
Reference in New Issue Copy Permalink