Vulkan-Docs/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt
Jon Leech 194a7f4d0d Change log for September 8, 2019 Vulkan 1.1.122 spec update:
* Update release number to 122.

Internal Issues:

  * Add style guide language on not using standalone `+` signs (internal
    issue 736); not using leading whitespace for markup (internal issue
    747); and on keeping descriptions of a single API in a contiguous block
    of markup (internal issue 949), and apply them to the specification.
  * Add a glossary definition of "`constant integral expression`", pointing
    to the SPIR-V "`constant instruction`" definition (internal issue 1225).
  * Many minor edits to improve writing style consistency and capture
    additional style guidelines (internal issue 1553).
  * Clarify that <<fragops-depth-write, depth writes are not performed>> if
    there is no depth framebuffer attachment (internal issue 1771).
  * Allow implementations to use rectangular line style of interpolation for
    <<primsrast-lines-bresenham, wide Bresenham lines>>, though replicating
    attributes is still preferred. Clarify that code:FragCoord is not
    replicated (internal issue 1772).
  * Resolve a contradiction in valid usage statements for
    slink:VkImageCreateInfo and slink:VkImageStencilUsageCreateInfoEXT
    (internal issue 1773).
  * Add style guide discussion of markup for indented equations, and use
    markup workaround for asciidoctor 2 compatibility (internal issue 1793).
  * Deprecate the `<<VK_EXT_validation_flags>>` extension in `vk.xml` and
    the extension appendix (internal issue 1801).
  * Add a new checker script `scripts/xml_consistency.py`. This is not
    currently run as part of internal CI (internal merge request 3285).
  * Correct "`an`" -> "`a`" prepositions where needed (internal merge
    request 3334).
  * Clarify that the <<features-uniformBufferStandardLayout,
    pname:uniformBufferStandardLayout>> feature is only required when the
    extension defining it is supported (internal merge request 3341).
  * Bring scripts into closer sync with OpenXR, mainly through conversion of
    comments to docstrings where appropriate, and add gen-scripts-docs.sh
    (internal merge request 3324).
  * Correct pname:maxDrawMeshTasksCount to 2^16^-1 in the <<limits-required,
    Required Limits>> table (internal merge requests 3361).

New Extensions

  * `<<VK_IMG_format_pvrtc>>` (public issue 512).
2019-09-08 20:41:02 -07:00

86 lines
3.2 KiB
Plaintext

// Copyright (c) 2014-2019 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[platformCreateSurface_android,platformCreateSurface_android]]
=== Android Platform
[open,refpage='vkCreateAndroidSurfaceKHR',desc='Create a slink:VkSurfaceKHR object for an Android native window',type='protos']
--
To create a sname:VkSurfaceKHR object for an Android native window, call:
include::{generated}/api/protos/vkCreateAndroidSurfaceKHR.txt[]
* pname:instance is the instance to associate the surface with.
* pname:pCreateInfo is a pointer to a sname:VkAndroidSurfaceCreateInfoKHR
structure containing parameters affecting the creation of the surface
object.
* pname:pAllocator is the allocator used for host memory allocated for the
surface object when there is no more specific allocator available (see
<<memory-allocation,Memory Allocation>>).
* pname:pSurface is a pointer to a slink:VkSurfaceKHR handle in which the
created surface object is returned.
During the lifetime of a surface created using a particular
dlink:ANativeWindow handle any attempts to create another surface for the
same dlink:ANativeWindow and any attempts to connect to the same
dlink:ANativeWindow through other platform mechanisms will fail.
[NOTE]
.Note
====
In particular, only one sname:VkSurfaceKHR can: exist at a time for a given
window.
Similarly, a native window cannot: be used by both a sname:VkSurfaceKHR and
code:EGLSurface simultaneously.
====
If successful, fname:vkCreateAndroidSurfaceKHR increments the
dlink:ANativeWindow's reference count, and fname:vkDestroySurfaceKHR will
decrement it.
On Android, when a swapchain's pname:imageExtent does not match the
surface's pname:currentExtent, the presentable images will be scaled to the
surface's dimensions during presentation.
pname:minImageExtent is [eq]#(1,1)#, and pname:maxImageExtent is the maximum
image size supported by the consumer.
For the system compositor, pname:currentExtent is the window size (i.e. the
consumer's preferred size).
include::{generated}/validity/protos/vkCreateAndroidSurfaceKHR.txt[]
--
[open,refpage='VkAndroidSurfaceCreateInfoKHR',desc='Structure specifying parameters of a newly created Android surface object',type='structs']
--
The sname:VkAndroidSurfaceCreateInfoKHR structure is defined as:
include::{generated}/api/structs/VkAndroidSurfaceCreateInfoKHR.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is reserved for future use.
* pname:window is a pointer to the dlink:ANativeWindow to associate the
surface with.
.Valid Usage
****
* [[VUID-VkAndroidSurfaceCreateInfoKHR-window-01248]]
pname:window must: point to a valid Android dlink:ANativeWindow.
****
include::{generated}/validity/structs/VkAndroidSurfaceCreateInfoKHR.txt[]
--
[open,refpage='ANativeWindow',desc='Android native window type',type='defines']
--
To remove an unnecessary compile-time dependency, an incomplete type
definition of dlink:ANativeWindow is provided in the Vulkan headers:
include::{generated}/api/defines/ANativeWindow.txt[]
The actual dlink:ANativeWindow type is defined in Android NDK headers.
--