summaryrefslogtreecommitdiffstats
path: root/libs/hwui/DisplayListRenderer.h
Commit message (Collapse)AuthorAgeFilesLines
* Skip eglSwapBuffers() call when we do not draw to GLChet Haase2012-05-311-20/+20
| | | | | | | | | | The fix is to track when we issue GL drawing commands, and to skip the call to eglSwapBuffers() when a DisplayList does not result in any actual rendering calls to GL. Issue #6364143 QuickMuni list items and buttons flicker instead of fade Change-Id: I60a02c61a58c32d92481a1e814b4c8a49c6a37a3
* Sanitize display list propertiesRomain Guy2012-05-181-9/+10
| | | | | | | | | | | The comparisons used in the various properties setters could fail badly in some specific conditions. The scale properties in particular did not use the same comparisons. This change also clamps alpha to the 0..1 range which avoids overflow issues with lowp registers in GLSL computations. Change-Id: I3e73b584e907a14e2c33d0865ca0d2d4d5bff31d
* Avoid unnecessary copy when invoking drawBitmap(int[])Romain Guy2012-05-151-22/+15
| | | | | | Bug #6483390 Change-Id: I4d2d725ef50c9401b4bd998b6160128102b40745
* Remove all Dalvik allocations from Cavnas.drawBitmap(int[], ...)Romain Guy2012-05-141-9/+29
| | | | Change-Id: Ie28538a2104d21154fdc78a56525e7403f08287d
* Merge "Fix issue where scale-animating text would jump temporarily a few ↵Chet Haase2012-05-071-1/+1
|\ | | | | | | pixels" into jb-dev
| * Fix issue where scale-animating text would jump temporarily a few pixelsChet Haase2012-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some logic in the native matrix code would determine that a matrix was 'pureTranslate' based on the scale values of a matrix being close-enough to 1, which was within a very small epsilon. This works in general, because screen space coordinates make that epsilon value irrelevant, so close-enough really is close-enough. However, TextView, when centering text, works in a coordinate system that is quite huge, with left/right values about 500,000. These numbers multiplied times that small epsilon value would give a result that was significant, and would cause a miscalculation of up to 4-5 pixels, causing the snap that we'd see for a couple of frames as the scale got "close enough" to 1. The fix is to remove the optimization of "close enough". What we really need the matrix to do is to identify itself as being translate-only when no scale as been set (which is the default). For the purposes of that check, it is good enough to simply check the values against 1 directly. Similarly, the bounds-check logic needs to check against 0 and 1 directly. Issue #6452687: Glitch when changing scale of a view containing text Change-Id: I167fb45d02201fb879deea0e5a7ca95e38128e17
* | Fix hang/crash in native path codeChet Haase2012-05-031-0/+11
|/ | | | | | | | | | | | | | | | An optimization for paths is to only create a texture for the original native Path object, and have all copies of that object use that texture. This works in most cases, but sometimes that original path object may get destroyed (when the SDK path object is finalized) while we are still referencing and using that object in the DisplayList code. This causes undefined errors such as crashes and hanging as we iterate through the operations of a destroyed (and garbage-filled) path object. The fix is to use the existing ResourceCache to refcount the original path until we are done with it. Issue #6414050 Analytics Dogfood App crashes reliably on Jellybean Change-Id: I5dbec5c069f7d6a1e68c13424f454976a7d188e9
* Remove USE_DISPLAY_LIST_PROPERTIES flagChet Haase2012-04-231-10/+12
| | | | | | | | | | | | | | | | This flag was still hanging around pending any need to disable DisplayList properties. But things seem stable, so it's time to clean up and simplify the code. At the same time, I reduced redundance in DisplayList dimensions. We used to call drawDisplayList() with width/height parameters that were used to do a clip reject. This is redundant with the DisplayList properties that set the bounds of the DisplayList; the left/right and top/bottom properties represent the same width/height properties formerly used in drawDisplayList(). The new approach is to not pass dimensions to drawDisplayList(), but to instead pull those dimensions directly from the DisplayList when needed. Change-Id: I8871beff03b1d4be95f7c6e079c31a71d31e0c56
* Optimization of alpha with DisplayList propertiesChet Haase2012-04-031-0/+5
| | | | | | | | | | | | Some views (such as ImageView and TextView) handle non-opaque alpha values directly. This was originally an optimization, but we can handle it faster in many cases without this optimization when DisplayList properties are enabled. Basically, if a view has non-overlapping rendering, we set the alpha value directly on the renderer (the equivalent of setting it on the Paint object) and draw each primitive with that alpha value. Doing it this way avoids re-creating DisplayLists while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties. Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
* Enabling DisplayList propertiesChet Haase2012-04-021-1/+1
| | | | | | | An earlier commit fixed problems with enabling DisplayList properties. This CL actually enables the properties. Change-Id: I5c41d0c64e9241822af53eb367de0fed7d9608e0
* Re-enable DisplayList properties.Chet Haase2012-04-021-5/+16
| | | | | | | | | | Re-enabling DisplayList properties last week caused some app errors due to the way that some transforms were being handled (specifically, those coming from the old Animations and ViewGroup's childStaticTransformation field). This change pushes *all* transform/alpha data from View.draw() into the view's DisplayList, making DisplayLists more encapsulated (and correct). Change-Id: Ia702c6aae050784bb3ed505aa87553113f8a1938
* Disable DisplayList properties pending fixes for AlphaAnimationChet Haase2012-03-291-1/+1
| | | | | | | | | The new DisplayList properties design has ordering conflicts with the way that alpha works with old animations (AlphaAnimation). This CL disables DiksplayList properties while I'm working on a fix and some more thorough tests for old animations-vs-DL properties in general. Change-Id: I8f6893138f939171491c2ec3c889214ee55d17b7
* Re-enabling DisplayList propertiesChet Haase2012-03-271-3/+1
| | | | | | | | | | | | | | | | | | | | | Several issues came up after DisplayList properties were enabled, so they were disabled pending fixes. Those issues have been fixed, so DisplayList properties are once again being enabled by default. This CL both re-enables these properties (in View.java and DisplayListRenderer.h) and fixes the various issues that enabling them caused the first time around. Related issues (all currently marked as Fixed, though that was simply because DL properties were disabled - this CL provides the real fixes now that DL properties are enabled by default): Issue #6198276 Text input broken Issue #6198472 Native crash at pc 00076428 in many different apps in JRM80 Issue #6204173 Date/time picker isn't rendering all parts of UI Issue #6203941 All Apps overscroll effect is rendered weirdly/has flickering Issue #6200058 CAB rendering issue - not drawing items? Issue #6198578 Front camera shows black screen after taking picture. Issue #6232010 Layers not recreated when children change (DisplayList properties) Change-Id: I8b5f9ec342208ecb20d3e6a60d26cf7c6112ec8b
* Use a status_t return type for GL functorsRomain Guy2012-03-261-3/+3
| | | | | | | | | WebView needs more fine-grained control over the behavior of the framework upon execution of the display lists. The new status_t allows WebView to requests its functor to be re-executed directly without causing a redraw of the entire hierarchy. Change-Id: I97a8141dc5c6eeb6805b6024cc1e76fce07d24cc
* Disable DisplayList propertiesChet Haase2012-03-221-1/+1
| | | | | | | | | | | | | | DisplayList properties are (again) disabled by default, via flags in View.java and DisplayListRenderer.h. There are various artifacts to chase down before enabling by default. Issue #6198472 Native crash at pc 00076428 in many different apps in JRM80 Issue #6204173 Date/time picker isn't rendering all parts of UI Issue #6203941 All Apps overscroll effect is rendered weirdly/has flickering Issue #6200058 CAB rendering issue - not drawing items? Issue #6198578 Front camera shows black screen after taking picture. Change-Id: I045dc82ce1d85fedbae3bb88eb2a2dfb6891d41f
* Enable DisplayList propertiesChet Haase2012-03-191-1/+1
| | | | | | | | | | | | | | | This CL simply enables DisplayList property functionality. The code for this feature is already there, but it's been disabled by default pending further testing and analysis. This change sets these build-type flags to true so that all hw-accelerated apps will now use DisplayList properties by default. In particular, this feature enables a fast-path for changes that affect the handful of View properties involved in animations (alpha, translationX, etc.). Setting these properties now gets propagated to the native DisplayList associated with the View, avoiding costly recreation of the SDK-level DisplayList and also enabling faster invalidation of the view hierarchy. Change-Id: Ic99c8f28fa9183f2e54e9e4860b333eb9c540f7c
* Set the default text length to -1, not 1Romain Guy2012-03-151-1/+1
| | | | Change-Id: Iccf6f8366c0b659ba7c90df99ae05ebc5d81fcbb
* Correctly compute the number of bytes written by each op.Romain Guy2012-03-131-5/+4
| | | | | | | | | | | | | Bug #6157792 Previously, DisplayListRenderer would compute the number of bytes written after a drawing op by looking at the difference between the start pointer of the command stream and the end pointer of the command stream. The SkWriter class used to record the commands stream allocates blocks of storage which would cause a crash when a command spanned two blocks. Change-Id: I4d79d3feeb6d72d9d4e6ab05ecebd72d004be56c
* Handle view properties at the native levelChet Haase2012-03-121-4/+268
| | | | | | | | | | | Basic functionality of handling View properties (transforms, left/right/top/bottom, and alpha) at the native DisplayList level. This logic is disabled for now (via compile-time flags in View.java and DisplayListRenderer.h) as we continue work on it (there is no advantage to the new approach until we optimize invalidation and rendering paths to use the new code path). Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
* Delete display list objects and resources on the UI threadRomain Guy2012-03-051-4/+4
| | | | | | | | | | | | | | Bug #6073717 Bug #6065504 Bug #6026515 Bug #5971725 Prior to this patch, the destructor of DisplayList would always run on the finalizer thread. This could cause a race condition if the UI thread was busy rendering display lists at the same time leading to various random native crashes. Change-Id: Ie11108e3b1538d4b358a1a8b4cce1b2d33152d0c
* Remove stray logRomain Guy2012-03-011-3/+5
| | | | Change-Id: I0c1979aab395098651c8a63d0bae0198ebc3746b
* Add hooks to implement Canvas.drawTextOnPath() in GLRomain Guy2012-02-241-0/+3
| | | | Change-Id: I165c9e05facf5365aa6850605688e538640c7fcc
* Only recreate path textures when necessaryRomain Guy2012-02-231-0/+1
| | | | | | | | | | | | | | When a drawPath command is recorded in a display list, a copy of the source path is made to preserve against possible modifications of the said source path. Copies are discarded when a display list is cleared, which usually happens on invalidate(). This means that even if a path is never modified, the texture generated to draw it on screen is destroyed every time an invalidate() is issued. This change fixes this problem by introducing a reference to the source path in the copy. If both the copy and the source path have the same genID, they are the same path and can share the same texture. Change-Id: I34849311c183e06336a1391d2d1568a087f973f6
* Only copy paths, paints and shaders when we need to.Romain Guy2012-02-211-3/+6
| | | | Change-Id: Iba7a9c92c865f698821b6ff7bc4f502659642ac1
* Record possible clip rejects when recording display listsRomain Guy2012-02-171-9/+52
| | | | | | | | | | | This optimization allows us to quickly skip operations that lie entirely outside of the known bounds of a display list. Because of ViewGroup.setClipChildren, we must keep the operations recorded in the display list. setClipChildren(false) is however a very uncommon operation and we will therefore often benefit from this new optimization. Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
* Add debug markers to OpenGLRendererRomain Guy2012-01-301-0/+10
| | | | | | | | These markers will be used to group the GL commands by View in the OpenGL ES debugging tool. This will help correlate individual GL calls to higher level components like Views. Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
* Add full support for Canvas.setDrawFilter()Romain Guy2012-01-231-2/+7
| | | | Change-Id: I0ad35d0603c4eeda469014803be14c1dcdde918c
* Fix the build, for realRomain Guy2012-01-191-1/+1
| | | | Change-Id: I6263f7e5e3ae2f7efe045f8b464c0ed1b87fc793
* First pass at implementing Canvas.drawPosText() in GLRomain Guy2012-01-171-0/+3
| | | | Change-Id: Ia3ac347e95d57eb86c63045156c8dbc0572b03cb
* Rename (IF_)LOGD(_IF) to (IF_)ALOGD(_IF) DO NOT MERGESteve Block2012-01-031-1/+1
| | | | | | | See https://android-git.corp.google.com/g/156016 Bug: 5449033 Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
* Clip text correctlyRomain Guy2011-12-051-1/+1
| | | | | | | | | | | | | | | | | Bug #5706056 A newly introduced optimization relied on the display list renderer to properly measure text to perform fast clipping. The paint used to measure text needs to have AA and glyph id encoding set to return the correct results. Unfortunately these properties were set by the GL renderer and not by the display list renderer. This change simply sets the properties in the display list renderer instead. This change also improves the error message printed out when the application attempts to use a bitmap larger than the max texture size. Change-Id: I4d84e1c7d194aed9ad476f69434eaa2c8f3836a8
* Faster text clippingRomain Guy2011-12-011-1/+1
| | | | Change-Id: I03a00c4261d81a416b1ad7b86ce2d432c71908b4
* Reduce the size of libhwui by 50%Romain Guy2011-10-121-48/+51
| | | | | | | | This change removes unnessary symbols. All symbols are hidden by default, public APIs with exported symbols are explicitly marked with ANDROID_API. Change-Id: I692fde432a86c12108de1cfd1f6504919a7d5f3f
* Optimize display listsRomain Guy2011-08-251-0/+14
| | | | | | Remove redundant or useless operations Change-Id: If989b4eaa9143eef4254c38b39959aeed1f2b9ab
* Reclaim more memory, more often.Romain Guy2011-07-271-0/+4
| | | | | | Yay. Change-Id: I04557ad575c307a55088549f48f0e9ad994b7275
* Destroy layers and flush layers cache when a window is destroyed.Romain Guy2011-07-271-1/+1
| | | | Change-Id: I3fa1bc3ff50fb99e3d2e490925bd6b0a0f809fff
* Decouple GLES20RecordingCanvas lifetime from GLES20DisplayList.Jeff Brown2011-07-211-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: 5062011 Previously, each GLES20DisplayList would hold onto an instance of GLES20RecordingCanvas. In turn, each GLES20RecordingCanvas held onto an SkWriter with a 16Kb buffer along with several other objects. With one display list per view and hundreds of views, the overhead could add up to a few megabytes. Ensured that the GLES20RecordingCanvas is reset as soon as the display list has been constructed, thereby promptly freeing the 16Kb buffer. Changed GLES20DisplayList so that it acquires a GLES20RecordingCanvas from a pool as needed and recycles it when done. Removed some dead code and cruft related to the construction of GLES20Canvas objects in general. Some code was written with the assumption that the underlying renderer object could change behind the scenes or might be lazily constructed, but that isn't actually the case so we can simplify things. Removed an unnecessary weak reference from GLES20DisplayList to the View. It isn't actually used anywhere. Fixed a bug in GLES20DisplayList where isValid() would return true while the display list was being recorded. This is incorrect because the native display list might not actually exist. Worse, even if the native display list does exist, it is stale and potentially refers to old Bitmaps that have been GC'd (because the mBitmaps list was cleared when recording started). Change-Id: Ib12d5483688cb253478edeb0156d34c476c2566b
* Fix another memory leak in OpenGLRendererRomain Guy2011-06-221-8/+6
| | | | Change-Id: I23ed56891452a05cf3ca13f6919c4fef90d5ff4e
* Fix memory leak in OpenGLRenderer.Romain Guy2011-06-221-1/+3
| | | | | | | | When creating a display list, matrices are duplicated locally. They were however never deleted, thus causing apps to slowly leak memory (a matrix is about 40 bytes.) Change-Id: Iac465b720d4c4c9b5ca3fce870c0c912c14a74ab
* Add ability for hierarchyviewer to output displaylist infoChet Haase2011-05-051-0/+2
| | | | | | | | | Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then clicking the new "Dump DisplayList" button will cause the display list for the selected node (including its children) to be output into logcat. Change-Id: Iad05f5f6cca0f8b465dccd962b501dc18fe6e053
* Revert "Add ability for hierarchyviewer to output displaylist info"Chet Haase2011-05-041-2/+0
| | | | This reverts commit b2a4b52e8d5e499d33e2765e8c47851bf0266299.
* Add ability for hierarchyviewer to output displaylist infoChet Haase2011-05-041-0/+2
| | | | | | | | | Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then clicking the new "Dump DisplayList" button will cause the display list for the selected node (including its children) to be output into logcat. Change-Id: Id32f62569ad1ab4d533bc62987f3a7390c1bb4e6
* Add logging of graphics acceleration info to bugreportsChet Haase2011-04-011-0/+3
| | | | Change-Id: I9fa4cda6ccf92df9d1c644ccdc0e7274a30106e0
* Add support for drawPoint() and drawPoints().Romain Guy2011-03-211-0/+2
| | | | Change-Id: I01bef50c08ec3160f8d40dc060b2cf6c2e4d7639
* Fix paths rendering issues.Romain Guy2011-03-181-15/+2
| | | | | | See ApiDemos, PathEffect and PathFillTypes. Change-Id: I9f9593c1da33d0d013b5b89c86bc5bd71128a192
* Fix rendering artifact in edge fades.Romain Guy2011-03-141-1/+11
| | | | | | | | | | | | | | | | | | Bug #4092053 The problem always existed but was made visible by partial invalidation. When saving a layer, the renderer would try to postpone glClear() operations until the next drawing command. This however does not work since the clip might have changed. The fix is rather simple and simply gets rid of this "optimization" (that turned out to be usless anyway given how View issues saveLayer() calls.) This change also fixes an issue with gradients (color stops where not properly computed when using a null stops array) and optimizes display lists rendering (quickly rejects larger portions of the tree to avoid executing unnecessary code.) Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
* Add support for partial invalidates in WebViewRomain Guy2011-03-071-3/+3
| | | | | | | | | | | | Bug #3461349 This change also fixes two bugs that prevented partial invalidates from working with other views. Both bugs were in our EGL implementation: they were preventing the caller from comparing the current context/surface with another context/surface. This was causing HardwareRenderer to always redraw the entire screen. Change-Id: I33e096b304d4a0b7e6c8f92930f71d2ece9bebf5
* Skia Merge (revision 808)Derek Sollenberger2011-02-221-1/+0
| | | | | | This is a companion CL to the one found in /external/skia Change-Id: If81748545435cab20a5d8479329ab333cb973e16
* Fix crash when Paths are GCd in hw accelerated appsChet Haase2011-02-041-0/+9
| | | | | | | | | | | | | | | | | | A recent change to optimize path rendering didn't account for the destruction of native objects by the VM finalizer. We may be done with the Java level version before we're done with the native structure that's used by the display list. For example, a drawing method on a View that creates a temporary path to render into the canvas will implicitly create a native structure that is put onto the GL display list. That temporary path may go away, but the native version should stick around as long as the display list does. The fix is to refcount the original native version of the path and only delete it when the refcoutn reaches zero (which means that it is no longer needed by any display list). This is a similar mechanism used for bitmaps and shaders. Change-Id: I4de1047415066d425d1c689aa60827f97729b470
* Fix leak in reused display listsChet Haase2011-02-031-1/+3
| | | | Change-Id: I32a9c41abf8f8cbcaaaa6fcc82d296800014a1b2
generated by cgit v1.1 at 2025-11-09 03:17:23 +0000