Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

4.4.2 - kot49n

OP Flypwnz

3rd February 2014, 04:07 PM   |  #11  
@wells's Avatar
Senior Member
Zagreb, HR
Thanks Meter: 363
 
466 posts
Join Date:Joined: Feb 2014
More
Quote:
Originally Posted by switch85

anyone knows if it has ART enabled by default in this release?

probably not as it was merged few days ago.
The Following User Says Thank You to @wells For This Useful Post: [ View ]
3rd February 2014, 04:14 PM   |  #12  
Senior Member
Thanks Meter: 607
 
1,991 posts
Join Date:Joined: May 2011
Quote:
Originally Posted by switch85

anyone knows if it has ART enabled by default in this release?

ART will not be enabled until the next major release. I highly doubt we will see it enabled in a bug fix release.
The Following User Says Thank You to bozzykid For This Useful Post: [ View ]
3rd February 2014, 05:14 PM   |  #13  
Senior Member
Flag Orangeville
Thanks Meter: 88
 
547 posts
Join Date:Joined: Oct 2009
Wonder if this release has the newest video drivers released by Qualcomm back on Jan 24th.

Release notes from this driver update:


•Add support for GL_EXT_multisampled_render_to_texture extension.
•Fix incorrect output with glReadPixels() on an FBO with a texture attachment which is a cubemap face.
•Fix incorrect lighting in the UBOTest example from the Adreno SDK. This fix addresses problems with scalar operations on UBOs.
•Performance enhancements for rasterizer discard.
•Performance enhancements for transform feedback.
•Fix issue with graphics driver being unable to find and load Adreno Profiler libraries.
•Cleaner handling for internal compiler error cases for UBOs.
•Faster rsGetElementAt() and rsSample() runtime performance for programs that access many Allocation objects.
•Improved stability when compiling complex RenderScript code.
•Allow a count of zero in calls to glDrawBuffers() as per spec.
•Fix errors in calculation of 2D texture array slice sizes for NPOT textures.
•Generate GL_INVALID_VALUE from glTexStorage2D() and glTexStorage3D() when width, height, or depth exceed supported size.
•Fix behavior of glGetFramebufferAttachmentParameteriv() to properly return GL_FRAMEBUFFER_DEFAULT for the default framebuffer instead of returning GL_NONE. (See OpenGLŪ ES Version 3.0 spec §6.1.13.)
•Change glCopyTexImage2D() to prohibit SNORM as a destination format, as per Table 3.15 of the OpenGLŪ ES Version 3.0 spec.
•Relaxed restrictions on the width and height parameters of glCompressedTexSubImage2D() to allow updates of 1x1 and 2x2 miplevels for ETC2/EAC formats. The incoming data buffer must still have its width and height padded to four, as required by ETC2/EAC, but the width and height parameters to the function call may reflect the actual texture dimensions.
•Fix a potential double-free of memory inside glLinkProgram().
•Fix reported value of gl_MaxVertexTextureImageUnits for GLES 3.0 hardware.
•Add support for the following built-in constants in GLSL 3.0:
◦gl_MaxVertexOutputVectors
◦gl_MaxFragmentInputVectors
◦gl_MinProgramTexelOffset
◦gl_MaxProgramTexelOffset
•Fix transposition of u and v coordinates in GLSL textureOffset() and texelFetch() functions.
•Fix loss of w coordinate in GLSL textureOffset() and texelFetch() functions.
•Fix GLSL matrix constructor to accept an array of matrices.
Last edited by Candy[MAN]; 3rd February 2014 at 05:22 PM.
3rd February 2014, 06:32 PM   |  #14  
rider5512's Avatar
Senior Member
Flag Buxton
Thanks Meter: 1,846
 
2,802 posts
Join Date:Joined: Feb 2010
More
Quote:
Originally Posted by switch85

anyone knows if it has ART enabled by default in this release?

I don't expect it will otherwise we'd see a bump in build number and anyway I hope not at least not until or even if Xposed becomes compatible. As much as I like the improvements ART brings I prefer my Xposed mods applied.
3rd February 2014, 06:54 PM   |  #15  
rayiskon's Avatar
Senior Member
Thanks Meter: 1,251
 
2,019 posts
Join Date:Joined: Jan 2011
People seem to forget that despite moving the ART change to the master branch, it may very well be excluded/reverted in future final builds. Just remember the camera changes that were excluded from the KitKat update.
So don't blame Google if ART is not the default runtime in the next version. I can already see those "this is not a complete update..." , "Google failed to deliver" ... comments being thrown around
The Following User Says Thank You to rayiskon For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes