<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 10:58 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 14-11-2014, at 10:44 AM, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
><br>
> I wonder where 10Mb of Bitmaps is being used…<br>
<br>
Well, duh, a 1700@1300 Display will do that, mostly. When did screens get so frakkin huge? Why, when I was a lad we had 640@400 monochrome and liked it!<br></blockquote><div><br></div><div>It would be cool if Spur could some how handle not saving the display bitmap to the snapshot, given that it'll be repainted anyway. But I want to avoid that old Smalltalk-80 behaviour of the screen visibly shrinking when the tracer is run. Let me throw this out as whitewash. Spur has a segmented memory and can and does avoid writing empty segments (segments that only contain free space) and trailing free space in segments. So if the Display bitmap were in a segment on its won (likely if it is reallocated on every snapshot launch) then with a little bit of finagling it might be simple to avoid writing it to the snapshot. There are obviously tricky details here such as what object it actually writes to the snapshot file. Anyway, something to think about when producing deployment images for the cloud.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
</span>There are two ways to write error-free programs; only the third one works.</blockquote></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>