{"action":"created","issue":{"url":"https://api.github.com/repos/schmie/hemeMove/issues/5","labels_url":"https://api.github.com/repos/schmie/hemeMove/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/schmie/hemeMove/issues/5/comments","events_url":"https://api.github.com/repos/schmie/hemeMove/issues/5/events","html_url":"https://github.com/schmie/hemeMove/issues/5","id":94099432,"number":5,"title":"Split ColPixel","user":{"login":"schmie","id":6473158,"avatar_url":"https://avatars.githubusercontent.com/u/6473158?v=3","gravatar_id":"","url":"https://api.github.com/users/schmie","html_url":"https://github.com/schmie","followers_url":"https://api.github.com/users/schmie/followers","following_url":"https://api.github.com/users/schmie/following{/other_user}","gists_url":"https://api.github.com/users/schmie/gists{/gist_id}","starred_url":"https://api.github.com/users/schmie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/schmie/subscriptions","organizations_url":"https://api.github.com/users/schmie/orgs","repos_url":"https://api.github.com/users/schmie/repos","events_url":"https://api.github.com/users/schmie/events{/privacy}","received_events_url":"https://api.github.com/users/schmie/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/schmie/hemeMove/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/schmie/hemeMove/labels/P:%20major","name":"P: major","color":"f6f6f6"}],"state":"open","locked":false,"assignee":{"login":"hcarver","id":1674771,"avatar_url":"https://avatars.githubusercontent.com/u/1674771?v=3","gravatar_id":"","url":"https://api.github.com/users/hcarver","html_url":"https://github.com/hcarver","followers_url":"https://api.github.com/users/hcarver/followers","following_url":"https://api.github.com/users/hcarver/following{/other_user}","gists_url":"https://api.github.com/users/hcarver/gists{/gist_id}","starred_url":"https://api.github.com/users/hcarver/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hcarver/subscriptions","organizations_url":"https://api.github.com/users/hcarver/orgs","repos_url":"https://api.github.com/users/hcarver/repos","events_url":"https://api.github.com/users/hcarver/events{/privacy}","received_events_url":"https://api.github.com/users/hcarver/received_events","type":"User","site_admin":false},"milestone":null,"comments":7,"created_at":"2015-07-09T16:50:11Z","updated_at":"2015-07-09T16:50:26Z","closed_at":null,"body":"**Reported by hywel on 19 Sep 2011 15:52 UTC**\nCurrently, we have a single !ColPixel object which holds the drawn pixel data for each component of the vis pipeline (glyper, ray tracer, streaker). This object also acts as the sole object transferred between cores to compose the image. The economy here is that the screen co-ordinates of each pixel are only in memory once per core.\r\n\r\nThe problems are:\r\n- our communications include unused bytes if we are not using one of the vis components. Ditto for pixels that don't have all 3 kinds of data.\r\n- we may want the data written to and communicated by each component to be dependent on the type of the component (e.g. we have already wanted to template the ray tracer on the way pixels from different cores are to be combined). This requires templating the !ColPixel on the specific component type, which in turn requires templating other components on that specific components type.\r\n- it makes it harder for us to add and remove visualisation components in real time.\r\n\r\nI'd like to remove the !ColPixel as a concept, and have each component use its own pixel type for storage and communication. These will only be composed into a single object just before being saved to file or sent to the client. \r\n\r\nAssigning to Rupert for design review."},"comment":{"url":"https://api.github.com/repos/schmie/hemeMove/issues/comments/120066602","html_url":"https://github.com/schmie/hemeMove/issues/5#issuecomment-120066602","issue_url":"https://api.github.com/repos/schmie/hemeMove/issues/5","id":120066602,"user":{"login":"schmie","id":6473158,"avatar_url":"https://avatars.githubusercontent.com/u/6473158?v=3","gravatar_id":"","url":"https://api.github.com/users/schmie","html_url":"https://github.com/schmie","followers_url":"https://api.github.com/users/schmie/followers","following_url":"https://api.github.com/users/schmie/following{/other_user}","gists_url":"https://api.github.com/users/schmie/gists{/gist_id}","starred_url":"https://api.github.com/users/schmie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/schmie/subscriptions","organizations_url":"https://api.github.com/users/schmie/orgs","repos_url":"https://api.github.com/users/schmie/repos","events_url":"https://api.github.com/users/schmie/events{/privacy}","received_events_url":"https://api.github.com/users/schmie/received_events","type":"User","site_admin":false},"created_at":"2015-07-09T16:50:26Z","updated_at":"2015-07-09T16:50:26Z","body":"**Comment by nick on 23 Sep 2011 14:26 UTC**\nReplying to [hywel](comment:6):\r\n> Small performance reduction for better engineered code is a good reason. And messages have to be significantly larger before you'll notice the performance difference.\r\nWhile I'll would full agree, the logical conclusion would be to use a language with garbage collection and reflection. I also understood the communication was the rate limiting step.\r\n \r\n> > > Nick, it's possible to have only the class that creates and consumes the data know about the type and nothing intermediate. The templating can therefore end at the boundary to the class. Run-type polymorphism is one way to handle this, encapsulation of the datatype is another (and the one I prefer).\r\n> > How the latter would work?\r\n> \r\n> You'd hand it a pointer and tell it to do what it needs to send data, then on the other side hand it a pointer and tell it to do what it needs to receive data from the pointer. External stuff only needs to know where its data starts and ends, nothing about what's inside.\r\nI thought the point of using MPI and why we used user defined data type rather than sizeof() was that it was architecture independent.\r\n \r\n \r\n> It shouldn't do, you should be able to give it a !LatticeData object and whatever else and tell the class to take what it needs. If you really wanted to avoid dynamic polymorphism, you could do this using the CRTP to get statically-typed objects that obey an interface.\r\nFair enough - I think the ray tracer is a special case in that it has the UpdateClusterVoxel method.\r\n\r\n> Only at the moment - the interaction between visualisation types on the level of the pixel is a bad smell. Like I say, code in the level above can decide how to combine colours, and that includes interactions.\r\nWhat about using the decorator pattern? You could also add extra classes that allow for transparency, eg having the streaklines at 50% opacity?"}}