summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add experimental-api guards for cogl_renderer_foreach_output()wip/frame-synchronizationOwen W. Taylor2013-01-291-0/+4
| | | | | | Since this API references CoglOutput, but occurs in a non-experimental header, we need to guard it so that an include of cogl.h without -DCOGL_ENABLE_EXPERIMENTAL_API doesn't beak.
* Fix return type for cogl_frame_info_get_refresh_rateOwen W. Taylor2013-01-292-2/+2
|
* Clean up Since: and Stability: for frame-info additionsOwen W. Taylor2013-01-284-8/+15
| | | | | | Consistently use Since: 1.14 Stability: Unstable for CoglFrameInfo related additions, also guard cogl-output.h and cogl-frame-info.h with COGL_ENABLE_EXPERIMENTAL_API.
* Don't convert gettimeofday() UST valuesOwen W. Taylor2013-01-281-14/+0
| | | | | | Instead of converting gettimeofday() UST values into clock_gettime(CLOCK_MONOTONIC, ...), just return them raw, and the caller can convert using cogl_clock_get_time().
* Add cogl_clock_get_time()Owen W. Taylor2013-01-284-0/+75
| | | | | | Add an API to get the current time in the time system that Cogl is reporting timestamps. This is to be used to convert timestamps into a different time system.
* Add documentation for CoglOutputOwen W. Taylor2013-01-281-1/+157
|
* Remove cogl_frame_info_get_complete()Owen W. Taylor2013-01-255-31/+4
| | | | | An application gets a callback when a frame info is complete, so there may not be a need for a flag as well.
* Replace frame history with a queueOwen W. Taylor2013-01-255-126/+28
| | | | | | An arbitrary-length frame history seems hard to size, and can be implemented at the application level, so ditch it for a queue of frame info objects that are not yet complete.
* Switch presentation time to nanosecondsOwen W. Taylor2013-01-252-16/+15
| | | | | | | In the future, we may want to track frame timings with very high precision for profiling purposes, so to be consistent with that, use nanoseconds, not microseconds. 63-bits in nanoseconds is 270+ years, so hopefully clock_gettime(CLOCK_MONOTONIC,) will fit.
* Don't use g_get_monotonic_time()Owen W. Taylor2013-01-252-29/+49
| | | | | | | | | | Avoid a hard dependency on GLib and on however GLib is implementing g_get_monotonic_time() by directly referencing clock_gettime(CLOCK_MONOTONIC). The translation of timestamp values for unidentified types of UST is also removed, since it's going to have a big error, and glXGetSyncValues() doesn't return the *current* UST anyways - it returns the UST for the last frame.
* Remove cogl_frame_info_get_frame_time()Owen W. Taylor2013-01-255-29/+2
| | | | | | | The frame_time isn't closely associated with an onscreen - an update could involve multiple stages (in a stage-per-output scenario, perhaps.) If an application or toolkit needs to know the frame time for a FrameInfo it will have to do that association itself.
* Add cogl_frame_info_get_output()Owen W. Taylor2013-01-254-14/+49
| | | | | | | | | If available from the windowing system, it could potentially be useful to know something other than the refresh rate of the output that the monitor is currently presenting on. (Note however, an onscreen may span multiple outputs. The windowing system has to pick *one* for timing, but most other attibutes of the window will apply to the parts of the onscreen on that output.)
* onscreen: Provide more general CoglFrameCallback apiRobert Bragg2013-01-249-198/+356
| | | | | | | | | | This reworks the cogl_onscreen_add_swap_complete_callback api to instead be named cogl_onscreen_add_frame_callback and to take a callback that can accept other events besides just swap completion events. This means we can add more events in the future that signal the progression of a frame without needing lots of new callback api for each event. TODO: squash this back into owen's patch
* renderer: expose CoglOutputsRobert Bragg2013-01-244-0/+103
| | | | | | | | This adds a cogl_renderer_foreach_output() function that can be used to iterate the display outputs for a particular renderer. This also updates cogl-info to use this new api so it can dump out all the output information.
* frame-info: s/_refresh_interval/_refresh_rate/Robert Bragg2013-01-244-15/+13
| | | | | | | For consistency this reworks the cogl_frame_info_get_refresh_interval api to instead be cogl_frame_info_get_refresh_rate() and return a frequency in Hertz instead of an interval in milliseconds. This is consistent with cogl_output_get_refresh_rate().
* rename SwapInfo to FrameInfoRobert Bragg2013-01-249-137/+137
| | | | | | | | | As discussed on the mailing list we can be slightly more consistent with gtk by using "frame" instead of "swap" here. Also we discussed the potential for being able to query information for a frame that's still in progress and in that case "swap" wouldn't make much sense. TODO: squash this back into owen's patch
* use c99 types if applicable and s/gboolean/CoglBool/Robert Bragg2013-01-236-14/+14
| | | | TODO: squash back into owen's patch
* rename CoglFrameTimings to CoglSwapInfoRobert Bragg2013-01-239-155/+158
| | | | | | | | | The aim is to pass an opaque structure to the swap buffers notification callbacks and enable access to frame timing information this way. Since there could be numerous non-timing related things to report here too this gives the structure a more general name. TODO: fold this back into owen's patch
* move outputs member up to CoglRendererRobert Bragg2013-01-233-17/+13
| | | | TODO: squash back into owen's patch
* use c99 types if applicable and s/gboolean/CoglBool/Robert Bragg2013-01-232-4/+4
| | | | TODO: squash back into owen's patch
* pedantic style fixesRobert Bragg2013-01-232-18/+34
| | | | TODO: squash back into owen's patch
* Add CoglFrameTimingsOwen W. Taylor2013-01-2311-15/+764
| | | | | | | | Add a CoglFrameTimings object that tracks timing information for frames that are drawn. We track a frame counter and frame timing information for each CoglOnscreen. Frames timing information is deliminated by a new cogl_onscreen_begin_frame() and retrieved using cogl_onscreen_get_frame_timings().
* Prefer OML_sync_control over SGI_video_sync when waiting for swapOwen W. Taylor2013-01-232-7/+50
| | | | | | When we block waiting for the swap, prefer doing that using glXWaitForMsc() from OML_sync_control because that returns a system time value for the precise time of the swap.
* Add missing cogl-output.cOwen W. Taylor2013-01-231-0/+110
| | | | Should have been part of "Add CoglOutput and track for the GLX backend"
* Add CoglOutput and track for the GLX backendOwen W. Taylor2013-01-238-9/+581
| | | | | | | | | | | The CoglOutput object represents one output such as a monitor or laptop panel, with information about attributes of the output such as the position of the output within the global coordinate space, and the refresh rate. We don't yet publically export the ability to get output information but we track it for the GLX backend, where we'll use it to track the refresh rate.
* Post-release version bump to 1.13.3Robert Bragg2013-01-221-2/+2
|
* Release 1.13.2 (snapshot)1.13.2Robert Bragg2013-01-221-4/+4
|
* Updates NEWS for the 1.13.2 releaseRobert Bragg2013-01-221-1/+43
|
* Remove vestiges of libdl / dlfcn.h as cogl uses gmodule.Patrick Welche2013-01-222-4/+0
| | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=691944 Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 397e673446e86a9116cb7396ea094e9f8b46986e)
* test-write-texture-formats: Add fuzziness to the pixel comparisonsNeil Roberts2013-01-223-11/+39
| | | | | | | | | | | | | | | The rounding used when storing 10-bit per component data into an 8-bit per component texture seems to have changed in recent versions of Mesa which was causing this test to fail. I've also noticed this failing on the NVidia binary driver. This patch adds some fuzziness to the comparison so that it will pass. There is a new test_utils function called test_utils_compare_pixel_and_alpha which is the same as test_utils_compare_pixel except that it also compares the alpha component. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit ce626fb3939b0f200d85ccdf32809608b879212d)
* tests: Mark test_framebuffer_get_bits as only working on GLNeil Roberts2013-01-221-1/+3
| | | | | | | | | | | | | It looks like it's not meant to be valid to create a framebuffer with an alpha-only texture as a render target on GLES. Since the following Mesa commit, this requirement is now enforced so that the test_framebuffer_get_bits test fails: http://cgit.freedesktop.org/mesa/mesa/commit/?id=cf300eaa Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit cfb0859cab843b000f4baa3ca155a245730edcfa)
* bitmap: Don't try to token paste the typenames from stdint.hNeil Roberts2013-01-222-86/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the functions for packing and unpacking pixels where generated by token pasting together a function name along with its type, like the following: _cogl_pack_ ## uint8_t Then later in cogl-bitmap-conversion.c it would directly refer to the function names without token pasting. This wouldn't work however if the system headers define the stdint types using #defines instead of typedefs because in that case the function name generated using token pasting would get the expanded type name but the reference that doesn't use token pasting wouldn't. This patch adds an extra macro passed to the cogl-bitmap-packing.h header which just has the type size. That way the function can be defined like this instead: _cogl_pack_ ## 8 That should prevent it from hitting problems with #defined types. https://bugzilla.gnome.org/show_bug.cgi?id=691945 Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d6b5d7085b004ebd48c1543b820331802395ee63)
* build: update to build with automake 1.13Robert Bragg2013-01-228-17/+17
| | | | | | | | | | | | This make autogen.sh look for automake-1.13 and also updates all Makefile.am files to no longer use the INCLUDES variable which automake 1.13 warns is deprecated by AM_CPPFLAGS. https://bugzilla.gnome.org/show_bug.cgi?id=690891 Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5de5569e960102afe979a5f2f0403e1defebca62)
* tests: flag backface culling failure without NPOT supportRobert Bragg2013-01-221-1/+1
| | | | | | This marks that test-backface-culling is currently known to fail without NPOT texture support. This allows us do a 1.13 snapshot release before we find a fix for this.
* disable viewport scissor workaround for clearRobert Bragg2013-01-221-0/+37
| | | | | | | | | We have a workaround in Cogl to fix viewport clipping with Mesa Intel Gen 6 drivers but this was breaking the semantics of cogl_framebuffer_clear() which should not be affected by viewport clipping. This makes sure we disable and restore the workaround when clearing the framebuffer. This fixes Clutter's test-cogl-viewport conformance test.
* Reorder some struct members to avoid padding due to alignmentNeil Roberts2013-01-226-23/+23
| | | | | | | | | | | | | | This tweaks the ordering of some struct members in some of the more important structs so that the compiler won't insert wasted padding to avoid breaking the alignment. Some members that were previously unsigned long have been changed to unsigned int. These members need to be able to fit in 32-bits to run on 32-bit machines anyway so there's no point in having them extend to 64-bit on 64-bit machines. This doesn't affect the public API. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b721af236680005464e39f7f4dd11381d95efb16)
* Fix filling the array of texture pointers for sliced texturesNeil Roberts2013-01-221-2/+0
| | | | | | | | | | | | | | | | In commit 1fa7c0f10a8a0 the sliced texture code which creates the array of pointers to the texture slices was changed so that the textures are appended to the end of the array instead of initially creating the array with the right size upfront and then shrinking the array on error. However it was then still also setting the size of the array after creating it so the new textures would actually end up in an unused part of the array. The part of the array that is used was left unitialised so it would crash. This just removes the call to set the size of the array. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 7df09d505ba28a1a960df867346af67118e96718)
* Don't try to use clip planes on GL3Neil Roberts2013-01-221-10/+13
| | | | | | | | | | | | GL3 has support for clip planes but they are used differently and involve writing to a builtin output variable in the vertex shader. The current clip plane code assumes it is only used with a fixed function driver and tries to directly push to the matrix builtins. This obviously won't work on GL3 so for now let's just disable clip planes. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 5f621589467ab961f5130590298dc8e26d658a92)
* framebuffer: Support the GL_RED texture workaround when querying bitsNeil Roberts2013-01-221-0/+10
| | | | | | | | | | | | | When a component-alpha texture is made using a GL3 context a GL_RED texture is actually used and a swizzle is set up to hide it. However if a framebuffer is then bound to that texture then when the bits are queried this workaround will leak out of the API. To fix this it now detects the situation and reports the number of red bits as the number of alpha bits. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 425cfb2675912a2cbcaaaeed7c2196d563948222)
* Query the framebuffer stencil bits instead of assuming it's globalNeil Roberts2013-01-227-38/+55
| | | | | | | | | | | | | | | Previously when the context was initialised Cogl would query the number of stencil bits and set a private feature flag to mark that it can use the buffer for clipping if there was at least 3. The problem with this is that the number of stencil bits returned by GL_STENCIL_BITS depends on the currently bound framebuffer. This patch adds an internal function to query the number of stencil bits in a framebuffer and makes it use that instead when determining whether it can push the clip using the stencil buffer. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit e928d21516a6c07798655341f4f0f8e3c1d1686c)
* Add a public cogl_framebuffer_get_depth_bits() functionNeil Roberts2013-01-225-2/+33
| | | | | | | | | Cogl publicly exposes the depth buffer state so we might as well have a function to query the number of depth bits of a framebuffer. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 853143eb10387f50f8d32cf09af31b8829dc1e01)
* framebuffer: Bind the framebuffer before querying the bitsNeil Roberts2013-01-228-92/+71
| | | | | | | | | | | | | | | The GL framebuffer driver now makes sure to bind the framebuffer before counting the number of bits. Previously it would just query the number of bits for whatever framebuffer happened to be used last. In addition the virtual for querying the framebuffer bits has been modified to take a pointer to a structure instead of a separate pointer to each component. This should make it slightly more efficient and easier to maintain. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit e9c58b2ba23a7cebcd4e633ea7c3191f02056fb5)
* Add a test for getting the component sizes from different fbsNeil Roberts2013-01-225-1/+52
| | | | | | | | | | | | | | | This adds a test which creates two offscreen framebuffers, one with just an alpha component texture and the other will a full RGBA texture. The bit sizes of both framebuffers are then checked to verify that they either have or haven't got bits for the RGB components. The test currently fails because the framebuffer functions don't bind the framebuffer before querying so they just query whichever framebuffer happened to be used last. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 7ca01373efe908efc9f18f2cb7f4a51c274ef677)
* Query glX* functions before getting the context to fix GL3 driverNeil Roberts2013-01-223-172/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GL3 context is created using the glXCreateContextAttribs function which is part of the GLX_ARB_create_context extension. However previously the function pointers from GLX extensions were only retrieved once the GL context is created. That meant that the GL3 context creation function would always assume that the extension is not supported so it would always fail. This patch changes it to query the functions when the renderer is set up instead. The base winsys feature flags that are determined while querying the functions are stored in a member of CoglGLXRenderer. These are then copied to the CoglContext when it is initialised. The spec for glXGetProcAddress says that the functions returned are context-independent. That implies that it is safe to call it without binding a context although that is not explicitly stated as far as I can tell. A big of googling finds this DRI documentation which says it can be used without a context: http://dri.freedesktop.org/wiki/glXGetProcAddressNeverReturnsNULL And also this code sample: http://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_%28GLX%29 One point that makes me concerned that this might not always work in practice is that the code in SDL2 to create a GL3 context first creates a dummy GL2 context in order to have something bound before it calls glXGetProcAddress. I think this may just be a misunderstanding based on how wglGetProcAddress works however. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 04a7aca9a98e84e43ac5559305a1358112902e30)
* Add a conformance test for some wrap modes on a rectangle textureNeil Roberts2013-01-225-8/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a conformance test which renders a rectangle texture using the two wrap modes clamp-to-edge and repeat. It then verifies that the correct region of the texture is drawn for the texture coordinates that are > 1.0. The test currently always fails. The cogl_framebuffer_draw_rectangle function is documented to always take normalized texture coordinates regardless of the coordinate system of the texture. This works correctly if all of the texture coordinates are in the range [0.0,1.0] because cogl-primitives uses a different code path in that case. However if the multiple-quad code path is taken then the coordinates actually need to un-normalized for it to work. There is a comment in cogl_meta_texture_foreach_in_region() which implies that the incoming coordinates should always be normalized. The documentation for the callback says that the resulting sub-texture coordinates will always be in the coordinate system of the low-level texture. However it doesn't work out like this because the meta texture function uses the span iterating function which always returns normalized coordinates. It looks like there needs to be some more conversions going on somewhere. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit d2059bb32b8015060e10f41dbbb68d4230b47ddb)
* Also flip the virtual coordinates when iterating spansNeil Roberts2013-01-222-7/+10
| | | | | | | | | | | | | | | | _cogl_texture_spans_foreach_in_region first swaps over the texture coordinates if they are flipped so that it can always iterate in a positive direction. It sets a flag so that it will remember that the coordinates are flipped. Before invoking the callback it is meant to reflip the coordinates so that the callee doesn't need to be aware of the flipping. However it was only flipping the sub-texture coordinates and not the virtual coordinates. This was causing sliced textures to draw their slice rectangles with the wrong geometry. test-backface-culling was failing because of this. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit e7338a1e09cb22151374aefa6f0bb58485af9189)
* texture-2d-slice: Fix the foreach_sub_texture_in_region implementationNeil Roberts2013-01-222-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were a few problems with the sub texture iterating code of sliced textures which were causing some conformance tests to fail when NPOT textures are disabled: • The spans are stored in un-normalized coordinates and the coordinates passed to the foreach function are normalized. The function was trying to un-normalize them before passing them to the span iterator code but it was using the wrong factor which was causing it to actually doubley normalize them. • The shim function to renormalize the coordinates before passing them to the callback was renormalizing the sub-texture coordinates instead of the virtual coordinates. The sub-texture coordinates are already in the right scale for whatever is the underlying texture so we don't need to touch them. Instead we need to normalize the virtual coordinates because these are coming from the un-normalized coordinates that we passed to the span iterating code. • The normalize factors passed to the span iterating were always 1. The code uses this normalizing factor to round the incoming coordinates to the nearest multiple of a full texture. It divides the coordinates by the factor rather than multiplying so it looks like we should be passing the virtual texture size here. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c9773566b0ec0a17b34c440090529de8cff9609e)
* texture: Adds cogl_texture_set_data convenience apiRobert Bragg2013-01-223-0/+89
| | | | | | | | | | | This adds a cogl_texture_set_data function that is basically just a convenience wrapper around cogl_texture_set_region. In the common case where you want to upload the full contents of a mipmap level though this api takes 4 less arguments (6 in total) so it's a bit simpler. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e651dbdc4e4f03016a3dee513e3680270a4a9142)
* Allow lazy texture storage allocationRobert Bragg2013-01-2237-417/+711
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistent with how we lazily allocate framebuffers this patch allows us to instantiate textures but still specify constraints and requirements before allocating storage so that we can be sure to allocate the most appropriate/efficient storage. This adds a cogl_texture_allocate() function that is analogous to cogl_framebuffer_allocate() which can optionally be called to explicitly allocate storage and catch any errors. If this function isn't used explicitly then Cogl will implicitly ensure textures are allocated before the storage is needed. It is generally recommended to rely on lazy storage allocation or at least perform explicit allocation as late as possible so Cogl can be fully informed about the best way to allocate storage. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 1fa7c0f10a8a03043e3c75cb079a49625df098b7) Note: This reverts the cogl_texture_rectangle_new_with_size API change that dropped the CoglError argument and keeps the semantics of allocating the texture immediately. This is because Mutter currently uses this API so we will probably look at updating this later once we have a corresponding Mutter patch prepared. The other API changes were kept since they only affected experimental api.
* texture: add width/height members to base CoglTextureRobert Bragg2013-01-2218-228/+104
| | | | | | | | | | | There was a lot of redundancy in how we tracked the width and height of different texture types which is greatly simplified by adding width and height members to CoglTexture directly and removing the get_width and get_height vfuncs from CoglTextureVtable Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 3236e47723e4287d5e0023f29083521aeffc75dd)
View Lorry Controller Status