On 2 March 2016 at 00:19, Andrew Baumann <andrew.baum...@microsoft.com> wrote: >> From: Peter Maydell [mailto:peter.mayd...@linaro.org] >> More interestingly, why can't you just read from the source >> pointer you're passed in here? The framebuffer_update_display() >> code should have obtained it by looking up the location of the >> host RAM where the guest video RAM is, so if you ignore it and >> do a complete physical-address-to-memory-region lookup for every >> pixel it's going to make redraws unnecessarily slow. > > That is what's happening for the 16-, 24- and 32-bit modes. For > 8-bit, it appears to be doing a palette lookup (using the 8-bit > value at the pointer as an index into the 256-colour palette > starting at vcram_base).
Oh, right, it's a palette lookup. That's fine, then. A comment mentioning that this is doing palette lookup would help. I wouldn't worry about efficiency for this mode because who's using 8-bit colour in 2016 ? thanks -- PMM
