# Changing EGLSurface size
**URL:** https://forums.imgtec.com/t/changing-eglsurface-size/1699
**Category:** PowerVR Insider
**Created:** [March 10, 2013, 4:19pm UTC](https://forums.imgtec.com/t/changing-eglsurface-size/1699 "2013-03-10T16:19:01Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@warmi](https://forums.imgtec.com/u/warmi)
#### Post date: [March 10, 2013, 4:19pm UTC](https://forums.imgtec.com/t/changing-eglsurface-size/1699/1 "2013-03-10T16:19:01Z")
I am using PVRFrame library for OSX as an alternative GLES2 only simulator for iOS devices ( it gives me native OpenGL performance vs Apple slow-ass software iOS simulator)
I got everything working fine except when I attempt to emulate screen orientation change by changing the underlying NSWindow size ( [nsWindow setFrame:frameFinal display:NO animate:NO]😉 to a new “rotated” size, I can’t get the underlying EGLContext to cooperate.
When I query EGL with :
eglQuerySurface(osx-\>mEGLDisplay, osx-\>mEGLWindow,
EGL\_WIDTH, (EGLint\*)&tmpW
);
eglQuerySurface(osx-\>mEGLDisplay, osx-\>mEGLWindow,
EGL\_HEIGHT, (EGLint\*)&tmpH
);
I get the correct new size but , despite updating glViewport with the new size etc … , all rendering seems to be corrupted ( following the old window size.)
The only way I can get it to work is by recreating EGLContext,EGLDisplay and EGLSurface from scratch which is workable but requires me to reload all GLES related resources …
Do you guys know if this is a potential bug in PVRFrame or if the underlying OSX implementation PVR frame is using, is to blame … ?
Thanks
---
### Author:  [@ChrisPenrose](https://forums.imgtec.com/u/ChrisPenrose)
#### Post date: [April 3, 2013, 9:48am UTC](https://forums.imgtec.com/t/changing-eglsurface-size/1699/2 "2013-04-03T09:48:57Z")
Hi Warmi, sorry for the delayed response. Somehow I missed this but a coworker pointed me here!
> Do you guys know if this is a potential bug in PVRFrame or if the underlying OSX implementation PVR frame is using, is to blame ... ?
Probably a little of both. This isn't something I have investigated yet but possibly we need to do something internally to update the underlying cocoa surface when the window size is changed. I've logged this as a bug for now and will try to reproduce it.