On 6/9/13 2:28 AM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >> Don't know OTOH. One possibility is that now that validateNow isn't >>being >> called it gets validated and the text is "fixed" on some later frame, >> which could be after compareBitmap does its thing. >As far as I can see the text shouldn't be changed/reversed/RTL or >anything as only the layoutDirection is changed. All that should do is >show columns in reverse order. >> >> I can put this on my list of things to dig into after I get other >>mustella >> failures on the VM resolved. Let me know. >If you could that would be a great help. Ok, finally got around to looking at this. The issue is that the renderer is based on UITextField which has different logic around invalidation. Just calling invalidateDisplayList on the renderer does not put it in the queue for later validation. I honestly don't know why we did that, maybe a performance optimization as UITextFields are usually subcomponents and are usually validated by their parent components. So, by removing the validateNow() call on the renderer, it leaves its invalidateDisplayList flag set but not in the queue which means that subsequent calls won't put it in the queue either, so it never get flipped back like it should. Putting the renderer in the queue on invalidateDisplayList() seems like a reasonable solution, but that will just re-introduce the calls to validateNow() defeating what I think you were trying to achieve, and means that other code that knows to call validateNow() will still end up calling validateNow() and then the LayoutManager will again, so there could be a performance hit. There aren't good checks on validateNow() to bail early if there isn't anything to do. So, I'll leave it up to you to decide whether to bring back that validateNow() and/or find a way to be smarter about not calling it, or adding queueing to the renderer (and maybe also do it for regular DGItemRenderer as well). HTH, -Alex
