On Mon, 2007-08-06 at 11:34 +0100, mark carter wrote: > I'm just throwing my thoughts > out there.
I've been thinking about this. I might try to to a bit of re-architecting. My problem is I know diddly-squat about threads, processes, and IPC. And I'm thinking that might be a good thing. It would be useful if I could separate out file loading. I also think that file loading and file saving are two entirely separate ideas, so I'd probably try to isolate them. You see, the way I figure it is that the purpose of a loader is to convert a foreign file format into a VFrame. I figure that if I could come up with an intermediate representation of a VFrame - one having a flat structure, then job of Cinelerra would be to interpret this intermediate representation. This ought to be fairly easy, because the representation would be designed with Cinelerra in mind. Debugging would be much easier - there'd be no threading stuff. You'd run the program, and "bam", it fails, so you look in gdb to find out what the problem is. Maybe use valgrind to get a really good idea of what the memory leaks are. Plus, you wouldn't have to compile the whole of Cinelerra, and the functionality could be tested in isolation. This idea has a number of other benefits. You could do something like farm out the loading process to other machines. And a pretty printer could be used to provide a summary of what's in the file for debugging purposes. It would have disadvantages, too - like more hard disk usage. It's the whole question of being clever as opposed to not being clever. Threads and suchlike are too clever. I don't understand them, and the received wisdom is that they're a whole world of hurt. So my idea is to be dumber, to try to isolate and modularise the problem; because at the end of the day, a program that can't be debugged is useless. Just my thinking. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
