Chromium Code Reviews
|
|
Chromium Code Reviews|
Created:
5 years ago by dshwang Modified:
5 years ago Reviewers:
dnicoara, reveman, piman, alexst (slow to review), kalyank, spang CC:
chromium-reviews, danakj+watch_chromium.org, darin-cc_chromium.org, jam, jbauman+watch_chromium.org, ozone-reviews_chromium.org, piman+watch_chromium.org, sievers+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Descriptionozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format.
It's follow-up for https://codereview.chromium.org/1401063002/
In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888
TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless
TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html
BUG=538325
Committed: https://crrev.com/466c3f1235fdfcabca07e351748ebc2678f59ffa
Cr-Commit-Position: refs/heads/master@{#366591}
Patch Set 1 #Patch Set 2 : improve #
Total comments: 4
Patch Set 3 : keep hardware overlay creating 24 bits plane #
Total comments: 6
Patch Set 4 : set framebuffer_pixel_format_ only if scanout #Patch Set 5 : ozone: support gfx::BufferFormat::RGBX_8888 #
Total comments: 4
Patch Set 6 : fix gl_image_ozone_native_pixmap also, which gl_unittests check #
Created: 5 years ago
Messages
Total messages: 35 (12 generated)
Description was changed from ========== ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888 It's follow-up for https://codereview.chromium.org/1401063002/ TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless BUG=538325 ========== to ========== ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888 It's follow-up for https://codereview.chromium.org/1401063002/ TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless BUG=538325 ==========
dongseong.hwang@intel.com changed reviewers: + alexst@chromium.org, reveman@chromium.org
dongseong.hwang@intel.com changed reviewers: + piman@chromium.org
alexst, reveman, could you review? It's follow-up for https://codereview.chromium.org/1401063002/
https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (left): https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ = GBM_FORMAT_XRGB8888; This hack was introduced by https://codereview.chromium.org/1314553002 Choosing XRGB or XRGB is role of drm_overlay_candidates_hosts, not here. It causes crash of gl_unittests in https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:18: fb_pixel_format_ = gbm_bo_get_format(bo); fb_pixel_format_ is used in GetBufferFormat() even for GPU_READ_WRITE buffer.
lgtm but we should really be querying gbm to find out what formats are supported. https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:18: fb_pixel_format_ = gbm_bo_get_format(bo); On 2015/11/27 at 17:59:54, dshwang_OOO_till_4thDec wrote: > fb_pixel_format_ is used in GetBufferFormat() even for GPU_READ_WRITE buffer. can you move this into the initialization list?
kalyan.kondapally@intel.com changed reviewers: + kalyan.kondapally@intel.com
https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:18: fb_pixel_format_ = gbm_bo_get_format(bo); On 2015/11/27 17:59:54, dshwang_OOO_till_4thDec wrote: > fb_pixel_format_ is used in GetBufferFormat() even for GPU_READ_WRITE buffer. Here storage format can be different to pixel format. This is not something OverlayCandidateHost can decide as it’s very specific to how we register the framebuffer. Currently, we always create fb of 24 bitcolordepth. GetFramebufferPixelFormat returns the Frame buffer format for this buffer. GetBufferFormat should return the pixel format, we could just query it directly from gbm there? If we want to cache the value than we need to separate it from fb_pixel_format_
LGTM for content/
Hi thanks for reviewing. I'm back from vacation. As kalyank notes, drm doesn't support 32bit plane for overlay. If launching with --ozone-test-single-overlay-support, patch set 2 crash when page flipping. kalyank introduces to create always 24 bits plane for BGRA in https://codereview.chromium.org/133350300 This CL extends the hack to cover RGBA also. In addition, GetFramebufferPixelFormat returns the actual format of the plane, while GetBufferFormat returns supporting format. kalyank, alexst, could you review again?
Description was changed from ========== ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888 It's follow-up for https://codereview.chromium.org/1401063002/ TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless BUG=538325 ========== to ========== ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888 It's follow-up for https://codereview.chromium.org/1401063002/ TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 ==========
On 2015/12/11 03:05:07, dshwang wrote: > Hi thanks for reviewing. I'm back from vacation. > > As kalyank notes, drm doesn't support 32bit plane for overlay. If launching with > --ozone-test-single-overlay-support, patch set 2 crash when page flipping. > kalyank introduces to create always 24 bits plane for BGRA in > https://codereview.chromium.org/133350300 > This CL extends the hack to cover RGBA also. In addition, > GetFramebufferPixelFormat returns the actual format of the plane, while > GetBufferFormat returns supporting format. > > kalyank, alexst, could you review again? Not sure what kernel version you are testing on, looks like you are missing support for "type" property. This is used to identify dedicated cursor plane and ensure we don't use it for any other purpose. As you actually were able to use Overlays, that means you ended up using Cursor plane to display Video buffer. This is because, we don't support ARGB format on any other plane than Cursor and format checks might have succeeded in Plane Manager. This might have resulted in binding the Video buffer to Cursor plane resulting in crash. What should really happen in this case is that we never end up using Overlays and not crash. I am not sure if I want to call it a hack :). As hardware doesn't yet have support for alpha composition, the framebuffers are registered as 24bit and planes (other than cursor) have support for XRGB. That's the reason we have split FrameBuffer Storage format from actual pixel format. This helps checking for right format support in plane manager.
https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:17: : drm_(drm), bo_(bo), fb_pixel_format_(gbm_bo_get_format(bo)) { Unless its a scanout buffer and the buffer is registered, fb_pixel_format_should just return 0. We should just leave this as before. https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ == GBM_FORMAT_ABGR8888) ABGR, is this format going to be used ?
alexst, kalyank, could you review again? On 2015/12/11 04:52:31, kalyank wrote: > Not sure what kernel version you are testing on, looks like you are > missing support for "type" property. This is used to identify > dedicated cursor plane and ensure we don't use it for any other > purpose. As you actually were able to use Overlays, > that means you ended up using Cursor plane to display Video > buffer. This is because, we don't support ARGB format > on any other plane than Cursor and format checks might have > succeeded in Plane Manager. This might have resulted in binding > the Video buffer to Cursor plane resulting in crash. > What should really happen in this case is that we never end up > using Overlays and not crash. I tests using amd64-generic_freon on Broadwell. chrome is fine, but content_unittests crash. This CL intends to fix content_unittests https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:17: : drm_(drm), bo_(bo), fb_pixel_format_(gbm_bo_get_format(bo)) { On 2015/12/11 04:57:41, kalyank wrote: > Unless its a scanout buffer and the buffer is registered, fb_pixel_format_should > just return 0. We should just leave this as before. Ok, agree. To clarify, rename it to framebuffer_pixel_format_; https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ == GBM_FORMAT_ABGR8888) On 2015/12/11 04:57:41, kalyank wrote: > ABGR, is this format going to be used ? ABGR is not used by chrome. However, ozone gbm supports ABGR scanout buffer, and content_unittests covers if it works. https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...
https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ == GBM_FORMAT_ABGR8888) On 2015/12/11 07:17:32, dshwang wrote: > On 2015/12/11 04:57:41, kalyank wrote: > > ABGR, is this format going to be used ? > > ABGR is not used by chrome. However, ozone gbm supports ABGR scanout buffer, and > content_unittests covers if it works. > https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... Only BGRA and RGBA are advertised. In BGRA case, format has to be GBM_FORMAT_BGRX8888.
Description was changed from ========== ozone: fix ozone crash about gfx::BufferFormat::RGBA_8888 It's follow-up for https://codereview.chromium.org/1401063002/ TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 ========== to ========== ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format. It's follow-up for https://codereview.chromium.org/1401063002/ In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888 TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 ==========
Change the CL's purpose; support gfx::BufferFormat::RGBX_8888 Currently, ozone supports RGBX_8888 incompletely. It's why content_unittests crashes. Support it completely. alexst, kalyank, could you review again? https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer_base.cc (right): https://codereview.chromium.org/1483633002/diff/40001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer_base.cc:21: fb_pixel_format_ == GBM_FORMAT_ABGR8888) On 2015/12/11 19:07:12, kalyank wrote: > On 2015/12/11 07:17:32, dshwang wrote: > > On 2015/12/11 04:57:41, kalyank wrote: > > > ABGR, is this format going to be used ? > > > > ABGR is not used by chrome. However, ozone gbm supports ABGR scanout buffer, > and > > content_unittests covers if it works. > > > https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... > > Only BGRA and RGBA are advertised. In BGRA case, format has to be > GBM_FORMAT_BGRX8888. Got it. New CL supports both BGRX8888 and RGBX8888. https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c... File ui/ozone/platform/drm/client_native_pixmap_factory_gbm.cc (right): https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c... ui/ozone/platform/drm/client_native_pixmap_factory_gbm.cc:53: format == gfx::BufferFormat::RGBX_8888 || ozone gbm supports RGBX also. https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c... File ui/ozone/platform/drm/common/drm_util.cc (right): https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/c... ui/ozone/platform/drm/common/drm_util.cc:310: int GetFourCCFormatForFramebuffer(gfx::BufferFormat format) { Now, this code is maintained by this function.
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right): https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat(); These changes now broke checks in VaapiWrapper. https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... Expectation is to return the framebuffer format here. Perhaps have another API like GetStorageFormat which returns the internal format and GetBufferFormat would return the pixel format as you have done.
https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right): https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat(); On 2015/12/15 00:55:12, kalyank wrote: > These changes now broke checks in VaapiWrapper. > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > Expectation is to return the framebuffer format here. Perhaps have another API > like GetStorageFormat which returns the internal format and GetBufferFormat > would return the pixel format as you have done. Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because Vaapi wants to decode directly into dma_buf. [1][2] [1] https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... [2] https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... So it doesn't break promise with VaapiWrapper. In addition (1), content (e.g. VaapiWrapper) should not know how ozone changes framebuffer format internally. It's so implementation detail. If something becomes wrong, ozone should handle it by itself. It's why I felt format changing is a bit hackish and move the code into one place. In addition (2), VaapiWrapper creates only BGRX_8888 and UYVY_422. When extending more format support for Vaapi, the switch statement should be updated at the time. VaapiWrapper is ozone client, not ozone.
On 2015/12/15 04:48:31, dshwang (in Korea) wrote: > https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... > File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right): > > https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... > ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat(); > On 2015/12/15 00:55:12, kalyank wrote: > > These changes now broke checks in VaapiWrapper. > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > > > Expectation is to return the framebuffer format here. Perhaps have another API > > like GetStorageFormat which returns the internal format and GetBufferFormat > > would return the pixel format as you have done. > > Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because Vaapi > wants to decode directly into dma_buf. [1][2] > [1] > https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... > [2] > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > So it doesn't break promise with VaapiWrapper. Well it does and I dont like vaapiWrapper making assumptions that this is the internal format for this given format. That should come from NativePixmap in this case, so in future when we have support for alpha composition/32 bit formats it should be handled in GbmBufferBase which is responsible for frame buffer registration. > In addition (1), content (e.g. VaapiWrapper) should not know how ozone changes > framebuffer format internally. It's so implementation detail. If something > becomes wrong, ozone should handle it by itself. It's why I felt format changing > is a bit hackish and move the code into one place. Not really, correct format needs to be used depending on the usage.Depending on if you want to sample from it or Scan it out, you need to know the format and internal/storage/framebuffer format. > > In addition (2), VaapiWrapper creates only BGRX_8888 and UYVY_422. When > extending more format support for Vaapi, the switch statement should be updated > at the time. VaapiWrapper is ozone client, not ozone.
On 2015/12/15 05:18:48, kalyank wrote: > On 2015/12/15 04:48:31, dshwang (in Korea) wrote: > > > https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... > > File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right): > > > > > https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... > > ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat(); > > On 2015/12/15 00:55:12, kalyank wrote: > > > These changes now broke checks in VaapiWrapper. > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > > > > > Expectation is to return the framebuffer format here. Perhaps have another > API > > > like GetStorageFormat which returns the internal format and GetBufferFormat > > > would return the pixel format as you have done. > > > > Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because Vaapi > > wants to decode directly into dma_buf. [1][2] > > [1] > > > https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... > > [2] > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > > > So it doesn't break promise with VaapiWrapper. > > Well it does and I dont like vaapiWrapper making assumptions that this is the > internal > format for this given format. That should come from NativePixmap in this case, > so > in future when we have support for alpha composition/32 bit formats it should be > handled in GbmBufferBase which is responsible for frame buffer registration. > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... You can check how this is being used here. Have you tried enabling Overlay support and play video ?
On 2015/12/15 05:22:00, kalyank wrote: > On 2015/12/15 05:18:48, kalyank wrote: > > On 2015/12/15 04:48:31, dshwang (in Korea) wrote: > > > > > > https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... > > > File ui/ozone/platform/drm/gpu/gbm_buffer.cc (right): > > > > > > > > > https://codereview.chromium.org/1483633002/diff/80001/ui/ozone/platform/drm/g... > > > ui/ozone/platform/drm/gpu/gbm_buffer.cc:145: return buffer_->GetFormat(); > > > On 2015/12/15 00:55:12, kalyank wrote: > > > > These changes now broke checks in VaapiWrapper. > > > > > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > > > > > > > Expectation is to return the framebuffer format here. Perhaps have another > > API > > > > like GetStorageFormat which returns the internal format and > GetBufferFormat > > > > would return the pixel format as you have done. > > > > > > Nope, VaapiWrapper requires format of dma_buf, not framebuffer, because > Vaapi > > > wants to decode directly into dma_buf. [1][2] > > > [1] > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/... > > > [2] > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > > > > > So it doesn't break promise with VaapiWrapper. > > > > Well it does and I dont like vaapiWrapper making assumptions that this is the > > internal > > format for this given format. That should come from NativePixmap in this case, > > so > > in future when we have support for alpha composition/32 bit formats it should > be > > handled in GbmBufferBase which is responsible for frame buffer registration. > > > https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > You can check how this is being used here. Have you tried enabling Overlay > support and > play video ? yes, as description said TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html Could you feedback again? do you think this CL lgtm?
> https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu... > > You can check how this is being used here. Have you tried enabling Overlay > > support and > > play video ? > > yes, as description said TEST=chrome --ozone-platform=gbm > --ozone-use-surfaceless --ozone-test-single-overlay-support > http://www.quirksmode.org/html5/tests/video.html > > Could you feedback again? do you think this CL lgtm? Non owner LGTM.
dongseong.hwang@intel.com changed reviewers: + spang@chromium.org
On 2015/12/15 06:27:50, kalyank wrote: > Non owner LGTM. Thank you for reviewing. alexst, spang, could you review ui/ozone?
kalyan.kondapally@intel.com changed reviewers: + dnicoara@chromium.org
On 2015/12/15 07:47:36, dshwang (in Korea) wrote: > On 2015/12/15 06:27:50, kalyank wrote: > > Non owner LGTM. > > Thank you for reviewing. > > alexst, spang, could you review ui/ozone? +dnicoara
lgtm
The CQ bit was checked by dongseong.hwang@intel.com
The patchset sent to the CQ was uploaded after l-g-t-m from reveman@chromium.org, piman@chromium.org, kalyan.kondapally@intel.com Link to the patchset: https://codereview.chromium.org/1483633002/#ps100001 (title: "fix gl_image_ozone_native_pixmap also, which gl_unittests check")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1483633002/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1483633002/100001
Message was sent while issue was closed.
Description was changed from ========== ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format. It's follow-up for https://codereview.chromium.org/1401063002/ In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888 TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 ========== to ========== ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format. It's follow-up for https://codereview.chromium.org/1401063002/ In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888 TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 ==========
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format. It's follow-up for https://codereview.chromium.org/1401063002/ In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888 TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 ========== to ========== ozone: support gfx::BufferFormat::RGBX_8888 as a native pixmap format. It's follow-up for https://codereview.chromium.org/1401063002/ In addition, this CL fixes content_unittests crash about gfx::BufferFormat::RGBA_8888 TEST=content_unittests --gtest_filter=GpuMemoryBuffer* --ozone-platform=gbm --ozone-use-surfaceless TEST=chrome --ozone-platform=gbm --ozone-use-surfaceless --ozone-test-single-overlay-support http://www.quirksmode.org/html5/tests/video.html BUG=538325 Committed: https://crrev.com/466c3f1235fdfcabca07e351748ebc2678f59ffa Cr-Commit-Position: refs/heads/master@{#366591} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/466c3f1235fdfcabca07e351748ebc2678f59ffa Cr-Commit-Position: refs/heads/master@{#366591} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
